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

[rupert THURNER]

i see, you are of course right. lets tackle it stepwise thought.

currently gar is syncronised manually on git and hg. lets assume we would
extend this experiment a little bit, deciding for the moment onto git. what
i would miss currently are two things:

1.  a short description how i set up my environment so i can deliver, say
mercurial. currently i do check out the whole mgar tree, the externals are
replaced with symbolic links. what would be the best approach if gar is in
git?

cd ~
pkg=mercurial
mkdir git-experiment
cd git-experiment
git clone https://rthurner@github.com/opencsw/gar.git gar
git svn clone
https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/${pkg} ${pkg}
ln -s ${pkg}/trunk/gar gar

2. how would i create a new package stub using git?


rupert


On Mon, Jun 20, 2011 at 03:27, Ben Walton <bwalton at opencsw.org> wrote:

> 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
>
> _______________________________________________
> maintainers mailing list
> maintainers at lists.opencsw.org
> https://lists.opencsw.org/mailman/listinfo/maintainers
> .:: This mailing list's archive is public. ::.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110625/7bb188a6/attachment.html>