[csw-maintainers] experimental: subversion --> git, mercurial

Ben Walton bwalton at opencsw.org
Mon Jun 20 03:27:20 CEST 2011


Excerpts from rupert THURNER's message of Sun Jun 19 09:00:55 -0400 2011:

Hi Rupert,

> as an experiment, i tried to convert the subversion gar repository to git
> and mercurial:
>  * http://code.google.com/p/gar/ (hg)
>  * https://github.com/opencsw/gar (git)

I like this! :)  I'm not keen on mercurial given my exposure to it,
but anything distributed would be a step up.

> what i am not sure is how to handle externals and patches onto them,
> but i saw posts like:
> *
> http://www.undefinedrange.com/posts/git-submodules-external-repositories-and-deployment

> what do you think, in general about a conversion, and in special,
> how to do this patching?

I'm not sure what you mean by 'patches onto them' but basically,
submodules suck for our use case, in my estimation.  They're excellent
in projects where you're pulling in external code as a source library.
The most common example I see is that many projects have gnulib as a
submodule.  When they're polishing a new release, they update the
gnulib submodule to current as part of that process.  They won't work
nicely in our pkg/$foo/trunk setup though as we'd be constantly
required to update the sha1 reference to the submodule for every
recipe change.

As Sebastian mentioned, we can (and should!) do away with externals
and, if they're still in use, the old garlinks in favour of the new
mgar wrapper.

If we did this, we could (as long as Sebastian is on board), merge
mgar directly into the gar/v2 git repository and release an actual
package for it.  mgar is packaged now, but it could be extended to
deliver the rest of the gar code with it.

The impact of this would be that people would be forced to use mgar to
interact with gar (or create their own new frankenstein) and people
would need to learn/use git.  Many of us are already using git where
possible, so that's not likely a big hurdle.  Using mgar is a positive
experience and doesn't change workflow much beyond s/(svn|gmake)/mgar/
now.

Gar would have a package and we could still have a devel mode for gar
where the local git (or hg) repo is tracked against the head of the
main branch.  Good for users, good for devs.

This might be a nice test of the waters for a move away from svn
instead of attempting to move gar and all of the recipes in one shot.

Is anyone else excited by this idea?

Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302



More information about the maintainers mailing list