Replacing the `elpa' branch

Replacing the `elpa' branch

[Stefan Monnier]

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

Re: Replacing the `elpa' branch

[Richard Stallman]

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

Re: Replacing the `elpa' branch

[Stefan Monnier]

> 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?

It would trigger the same problem, indeed.  The thing that triggers the
bug is the exact thing we want.


        Stefan

Re: Replacing the `elpa' branch

[Leo Liu]

On 2013-02-16 22:06 +0800, Richard Stallman wrote:
> The situation with bzr seems to be bad.  I am talking with the maintainer
> to determine what to do with it.

Yes, bzr situation is pretty sad and bad; see the insight from someone
deeply involved with bzr:  

  Title: Bazaar-NG: 7 years of hacking on a distributed version control system
  URL: http://stationary-traveller.eu/pages/bzr-a-retrospective.html

Leo

Re: Replacing the `elpa' branch

[Ted Zlatanov]

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

Re: Replacing the `elpa' branch

[Fabian Ezequiel Gallina]

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

Re: Replacing the `elpa' branch

[Stefan Monnier]

>> 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

Re: Replacing the `elpa' branch

[Andreas Schwab]

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."

Re: Replacing the `elpa' branch

[Jorgen Schaefer]

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

Re: Replacing the `elpa' branch

[Andreas Schwab]

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."

Re: Replacing the `elpa' branch

[Jorgen Schaefer]

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

Re: Replacing the `elpa' branch

[Andreas Schwab]

Jorgen Schaefer <forcer@forcix.cx> writes:

> I was not aware that this would keep the "remote" information.

Which "remote" information?

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."

Re: Replacing the `elpa' branch

[Achim Gratz]

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

Re: Replacing the `elpa' branch

[Jorgen Schaefer]

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

Re: Replacing the `elpa' branch

[Dmitry Gutov]

Jorgen Schaefer <forcer@forcix.cx> writes:
> This then is only missing js2-mode, which is hosted on subversion. I

No, it isn't.

> 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

The upstream is here: https://github.com/mooz/js2-mode/

Re: Replacing the `elpa' branch

[Jorgen Schaefer]

On Sun, 10 Mar 2013 21:37:38 +0400
Dmitry Gutov <dgutov@yandex.ru> wrote:

> Jorgen Schaefer <forcer@forcix.cx> writes:
> > This then is only missing js2-mode, which is hosted on subversion. I
> 
> No, it isn't.
> 
> > 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
> 
> The upstream is here: https://github.com/mooz/js2-mode/

Wonderful. That makes things a lot easier. :-)

	-- Jorgen

Re: Replacing the `elpa' branch

[Andreas Schwab]

Jorgen Schaefer <forcer@forcix.cx> writes:

> 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

aka git clone --single-branch -b elpa git://git.sv.gnu.org/emacs elpa

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."