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://[email protected]/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 <[email protected]> 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 > [email protected] > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::. >
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
