|
| From: | Michael Goffioul |
| Subject: | Re: Plan to move gnulib to hg |
| Date: | Sat, 9 Mar 2013 12:10:02 -0500 |
Summary: Im replacing the git gnulib subrepo with an hg clone.
This may introduce some instability, so you'll have to do a fresh
rebuild and delete the gnulib/ directory manually. It may be easier to
do a fresh clone altogether.
There are some problems with having gnulib as a git subrepo. Casual
contributors face the problem of needing to install two DVCSes in
order to clone the Octave sources. We have the problem that this git
subrepo also breaks the "D" part of the DVCS acronym, since we are
mostly tied to whatever the gnulib devs do with no write access
ourselves. It makes sense for us to have our own gnulib clone with
write access, for example, so we can have a stable and default gnulib
branch that matches Octave's own branches. This latter problem has in
fact slowed down the 3.6.4 release, since we need to backport a
specific gnulib fix to stable.
I have made two changes to the gnulib subrepo to alleviate these
problems:
1) Convert the gnulib repo to an hg mirror:
http://hg.octave.org/gnulib
Result: no more git in Octave.
2) Change the git url to a trivial gnulib-hg = gnulib-hg entry in
.hgsub, in accordance with these suggestions:
http://mercurial.selenic.com/wiki/Subrepository#Use_.27trivial.27_subrepo_paths_where_possible
Result: this allows us to treat the gnulib subrepo in a more
distributed way, by keeping our own clone of it where we can do
whatever we want, including adding new commits to it. This
subrepo will be distributed on every clone of Octave via the
usual hg commands, fetched from the same location as the Octave
clone itself.
Thus in the future if you want to update the hg gnulib repo, pull from
the above hg.octave.org url, but this url will not be recorded in hg
history. You may, as a convenience, define something like this in your
~/.hgrc or your Octave clone's .hg/hgrc:
[paths]
oct-gnulib = http://hg.octave.org/gnulib
Then you can do "hg pull oct-gnulib" inside the gnulib-hg subrepo in
order to update it. Note that the hg.octave.org gnulib clone is
read-only; it's just meant to mirror the original git so that we can
pull in new changes from the gnulib maintainers. Our changes,
hopefully small, will go in the gnulib-hg subrepo that will get
distributed along with the main Octave repository itself in a
proper DVCS fashion.
There may be some trouble I am not foreseeing in the immediate future
because of this. Also, we're stuck with the old history pointing to an
external url. You may wish to use a subpath and keep a local clone of
the current git repo, with the following in your ~/.hgrc or in your
Octave clone's .hg/hgrc:
[subpaths]
git://git.sv.gnu.org/gnulib = /local/git/clone/of/gnulib
There's no need to update this optional clone, it's just for
inspecting old history.
There is one further complication. Our hg repo will of course have
different hashes than the git upstream. The actual mirror at
hg.octave.org above, though, contains metadata that maps git hashes to
hg hashes, which is useful for communicating with upstream gnulib
maintainers. If you need to refer to the original git hashes, you may
acquire this metadata by using hg-git to recreate the hg mirror or by
downloading this git-mapfile:
http://octave.org/gnulib-git-mapfile
The first column is git hashes, the second column is the corresponding
hg hashes. This is probably a temporary url for this file. I am
thinking of patching hg-git so that it adds a --gitdata option to "hg
pull" so you can also acquire this metadata when you pull from
the hg.octave.org mirror.
With a recent version of hg-git, the following hg commands help to
translate one to the other if you have an hg-git clone of gnulib (i.e.
one that includes the git metadata):
hg log -r "gitnode($githash)"
hg log -r $hgrev_or_hash --template '{gitnode}\n'
Happy new year,
- Jordi G. H.
| [Prev in Thread] | Current Thread | [Next in Thread] |