* Replacing the `elpa' branch
@ 2013-02-15 20:33 Stefan Monnier
2013-02-16 14:06 ` Richard Stallman
2013-02-25 16:32 ` Ted Zlatanov
0 siblings, 2 replies; 17+ messages in thread
From: Stefan Monnier @ 2013-02-15 20:33 UTC (permalink / raw
To: emacs-devel
As many of you know, the `elpa' branch is kind of sick: while the branch
itself is actually fine, Bzr chokes on it when doing the initial
checkout (the checkout is still possible, if you know the trick).
This bug in Bzr has been reported at least since October 2011 and
still isn't fixed, so given the lack of development of Bazaar, we can
mostly assume it won't be fixed.
We could rewrite the `elpa' branch, throwing away the crucial info that
triggers the bug, but it's an info I'd like to keep (it's the merge
metadata that lets us merge from externally maintained branches of elpa
packages).
Luckily there's one way forward: using a Git branch for `elpa'.
Joergen Schaefer and John Wiegley are working at producing a Git
branch that preserves the metadata we currently have in `elpa'.
I don't want this to be a discussion about the merits/pitfalls of Git vs
Bzr, and this is not an occasion to discuss the use of Git for the
`trunk' either. It's just the only way forward to fix this long
standing and embarrassing problem on the `elpa' branch.
I'm not terribly happy about this change, since it means we'll be using
two different tools (Git for `elpa' and Bzr for `trunk'), but I really
see no other way out. So this is mostly a heads up.
If someone (and no, not someone like Glenn who's already busy enough)
could take care of adjusting the scripts in elpa/admin, that would
be appreciated.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-02-15 20:33 Replacing the `elpa' branch Stefan Monnier
@ 2013-02-16 14:06 ` Richard Stallman
2013-02-16 14:31 ` Stefan Monnier
2013-02-18 6:33 ` Leo Liu
2013-02-25 16:32 ` Ted Zlatanov
1 sibling, 2 replies; 17+ messages in thread
From: Richard Stallman @ 2013-02-16 14:06 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
The situation with bzr seems to be bad. I am talking with the maintainer
to determine what to do with it.
In the mean time, is it possible to recreate the elpa Bzr branch
based on what is in the git repository? Or would that trigger the same
bug again?
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-02-15 20:33 Replacing the `elpa' branch Stefan Monnier
2013-02-16 14:06 ` Richard Stallman
@ 2013-02-25 16:32 ` Ted Zlatanov
2013-03-09 5:02 ` Fabian Ezequiel Gallina
1 sibling, 1 reply; 17+ messages in thread
From: Ted Zlatanov @ 2013-02-25 16:32 UTC (permalink / raw
To: emacs-devel
On Fri, 15 Feb 2013 15:33:50 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
SM> I'm not terribly happy about this change, since it means we'll be using
SM> two different tools (Git for `elpa' and Bzr for `trunk'), but I really
SM> see no other way out. So this is mostly a heads up.
SM> If someone (and no, not someone like Glenn who's already busy enough)
SM> could take care of adjusting the scripts in elpa/admin, that would
SM> be appreciated.
Let me know here or over e-mail what needs to be done. I plan to do
some work with the ELPA anyhow after the 24.3 release (to address the
things that came up during the ELPA security discussion).
Ted
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-02-25 16:32 ` Ted Zlatanov
@ 2013-03-09 5:02 ` Fabian Ezequiel Gallina
2013-03-10 5:18 ` Stefan Monnier
0 siblings, 1 reply; 17+ messages in thread
From: Fabian Ezequiel Gallina @ 2013-03-09 5:02 UTC (permalink / raw
To: emacs-devel
2013/2/25 Ted Zlatanov <tzz@lifelogs.com>:
> On Fri, 15 Feb 2013 15:33:50 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> Let me know here or over e-mail what needs to be done. I plan to do
> some work with the ELPA anyhow after the 24.3 release (to address the
> things that came up during the ELPA security discussion).
>
What's the status of the ELPA branch replacement?
Regards,
Fabián
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-09 5:02 ` Fabian Ezequiel Gallina
@ 2013-03-10 5:18 ` Stefan Monnier
2013-03-10 8:06 ` Andreas Schwab
2013-03-10 16:51 ` Jorgen Schaefer
0 siblings, 2 replies; 17+ messages in thread
From: Stefan Monnier @ 2013-03-10 5:18 UTC (permalink / raw
To: Fabian Ezequiel Gallina; +Cc: johnw, Jorgen Schaefer, emacs-devel
>> Let me know here or over e-mail what needs to be done. I plan to do
>> some work with the ELPA anyhow after the 24.3 release (to address the
>> things that came up during the ELPA security discussion).
> What's the status of the ELPA branch replacement?
Haven't had time to devote to it. AFAIK, there's a Git version of the
branch (prepared by Joergen), with the following needs:
1- update it to ELPA's tip.
2- install it somehow into git.sv.gnu.org.
3- update the scripts on elpa.gnu.org.
I think the first step now is to figure out how to do step 2.
Once this is settled, we can do step 1 and then 2. Step 3 can come
later without too much trouble.
Stefan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 5:18 ` Stefan Monnier
@ 2013-03-10 8:06 ` Andreas Schwab
2013-03-10 10:19 ` Jorgen Schaefer
2013-03-10 16:51 ` Jorgen Schaefer
1 sibling, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2013-03-10 8:06 UTC (permalink / raw
To: Stefan Monnier
Cc: johnw, emacs-devel, Jorgen Schaefer, Fabian Ezequiel Gallina
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> I think the first step now is to figure out how to do step 2.
git push git.sv.gnu.org:emacs/elpa will do it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 8:06 ` Andreas Schwab
@ 2013-03-10 10:19 ` Jorgen Schaefer
2013-03-10 11:57 ` Andreas Schwab
2013-03-10 12:44 ` Achim Gratz
0 siblings, 2 replies; 17+ messages in thread
From: Jorgen Schaefer @ 2013-03-10 10:19 UTC (permalink / raw
To: Andreas Schwab
Cc: johnw, Fabian Ezequiel Gallina, Stefan Monnier, emacs-devel
On Sun, 10 Mar 2013 09:06:28 +0100
Andreas Schwab <schwab@linux-m68k.org> wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
> > I think the first step now is to figure out how to do step 2.
>
> git push git.sv.gnu.org:emacs/elpa will do it.
The problem we have faced I think was that elpa includes a number of
other projects as subtrees (using read-tree). The question was mostly
how to transport this information, in particular the "remote" branches,
to the git repository, as .git/config isn't chared. Alternatively, we
can use submodules for this. I'm not deep enough into git to understand
whether one or the other is "better" here.
Especially considering the one package using svn. I never used git-svn
for anything but trivial tasks, so I again have no idea how to include
that without a separate git repository that only tracks the svn one.
Regards,
-- Jorgen
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 10:19 ` Jorgen Schaefer
@ 2013-03-10 11:57 ` Andreas Schwab
2013-03-10 12:06 ` Jorgen Schaefer
2013-03-10 12:44 ` Achim Gratz
1 sibling, 1 reply; 17+ messages in thread
From: Andreas Schwab @ 2013-03-10 11:57 UTC (permalink / raw
To: Jorgen Schaefer
Cc: johnw, Fabian Ezequiel Gallina, Stefan Monnier, emacs-devel
Jorgen Schaefer <forcer@forcix.cx> writes:
> The problem we have faced I think was that elpa includes a number of
> other projects as subtrees (using read-tree). The question was mostly
> how to transport this information, in particular the "remote" branches,
You can push any branch, just name it in a refspec.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 11:57 ` Andreas Schwab
@ 2013-03-10 12:06 ` Jorgen Schaefer
2013-03-10 16:35 ` Andreas Schwab
0 siblings, 1 reply; 17+ messages in thread
From: Jorgen Schaefer @ 2013-03-10 12:06 UTC (permalink / raw
To: Andreas Schwab; +Cc: johnw, Andreas Schwab, emacs-devel
On Sun, 10 Mar 2013 12:57:17 +0100
Andreas Schwab <schwab@linux-m68k.org> wrote:
> Jorgen Schaefer <forcer@forcix.cx> writes:
>
> > The problem we have faced I think was that elpa includes a number of
> > other projects as subtrees (using read-tree). The question was
> > mostly how to transport this information, in particular the
> > "remote" branches,
>
> You can push any branch, just name it in a refspec.
I was not aware that this would keep the "remote" information.
Regards,
-- Jorgen
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 10:19 ` Jorgen Schaefer
2013-03-10 11:57 ` Andreas Schwab
@ 2013-03-10 12:44 ` Achim Gratz
1 sibling, 0 replies; 17+ messages in thread
From: Achim Gratz @ 2013-03-10 12:44 UTC (permalink / raw
To: emacs-devel
Jorgen Schaefer writes:
> Especially considering the one package using svn. I never used git-svn
> for anything but trivial tasks, so I again have no idea how to include
> that without a separate git repository that only tracks the svn one.
Git svn is one of those converters that actually work both ways, so
there is nothing to fear. As with all new tools, you'd be well advised
to set up clones for both SVN and the Git repo to try and break it and
maybe adapt your workflow according to your results.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Replacing the `elpa' branch
2013-03-10 5:18 ` Stefan Monnier
2013-03-10 8:06 ` Andreas Schwab
@ 2013-03-10 16:51 ` Jorgen Schaefer
2013-03-10 17:37 ` Dmitry Gutov
2013-03-10 18:52 ` Andreas Schwab
1 sibling, 2 replies; 17+ messages in thread
From: Jorgen Schaefer @ 2013-03-10 16:51 UTC (permalink / raw
To: Stefan Monnier; +Cc: johnw, Stefan Monnier, emacs-devel
On Sun, 10 Mar 2013 00:18:52 -0500
Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> >> Let me know here or over e-mail what needs to be done. I plan to
> >> do some work with the ELPA anyhow after the 24.3 release (to
> >> address the things that came up during the ELPA security
> >> discussion).
> > What's the status of the ELPA branch replacement?
>
> Haven't had time to devote to it. AFAIK, there's a Git version of the
> branch (prepared by Joergen)
Just so I'm not the only one with this "arcane" knowledge. It's not
really difficult to prepare a git version of bzr, just requires some
non-obvious incantations:
mkdir elpa-migration
cd elpa-migration
bzr branch https://code.launchpad.net/~schwab-linux-m68k/bzr-fastimport/master fastimport
export BZR_PLUGIN_PATH=$HOME/elpa-migration
export PYTHONPATH=$HOME/elpa-migration/
mkdir bzr ; cd bzr
bzr branch http://bzr.savannah.gnu.org/r/emacs/elpa
cd elpa
bzr revert
cd ../..
mkdir -p git/elpa ; cd git/elpa ; git init
bzr fast-export --plain ~/elpa-migration/bzr/elpa/ | git fast-import --force
git checkout
This results in a git copy of the ELPA bzr repository, but it's lacking
information about all the upstream repositories the bzr repo is tracking.
I used read-tree to import them, but it might be better to use submodule.
I know too little about git and the uses here to make a decision.
Repositories to be tracked:
f90-interface-browser https://github.com/wence-/f90-iface/
coffee-mode https://github.com/defunkt/coffee-mode
ioccur https://github.com/thierryvolpiatto/ioccur
yasnippet https://github.com/capitaomorte/yasnippet
ggtags https://github.com/leoliu/ggtags
ack-el https://github.com/leoliu/ack-el
For each of those, I did the following:
git remote add $PACKAGE $URL
git fetch -n $PACKAGE
git checkout -b $PACKAGE $PACKAGE/master
git checkout master
I then merged each of them with a separate commit using the following:
git rm -r packages/$PACKAGE
git read-tree --prefix=packages/$PACKAGE -u $PACKAGE
git add packages/$PACKAGE
git commit -m "Merged packages/$PACKAGE from $URL"
This then is only missing js2-mode, which is hosted on subversion. I
do not use git-svn much at all and have no idea how to do a read-tree
or submodule with that. The svn repo is hosted here:
svn checkout http://js2-mode.googlecode.com/svn/trunk/ js2-mode-read-only
It might be best if someone who has more clue about both git and how
elpa is used picks up from here.
Regards,
-- Jorgen
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-03-10 18:52 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-15 20:33 Replacing the `elpa' branch Stefan Monnier
2013-02-16 14:06 ` Richard Stallman
2013-02-16 14:31 ` Stefan Monnier
2013-02-18 6:33 ` Leo Liu
2013-02-25 16:32 ` Ted Zlatanov
2013-03-09 5:02 ` Fabian Ezequiel Gallina
2013-03-10 5:18 ` Stefan Monnier
2013-03-10 8:06 ` Andreas Schwab
2013-03-10 10:19 ` Jorgen Schaefer
2013-03-10 11:57 ` Andreas Schwab
2013-03-10 12:06 ` Jorgen Schaefer
2013-03-10 16:35 ` Andreas Schwab
2013-03-10 12:44 ` Achim Gratz
2013-03-10 16:51 ` Jorgen Schaefer
2013-03-10 17:37 ` Dmitry Gutov
2013-03-10 17:41 ` Jorgen Schaefer
2013-03-10 18:52 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.