DragonFly kernel List (threaded) for 2008-10
Re: Source Control system results and discussion
> I propose first that the DragonFly repository be officially accessible
> via both Git and Mercurial. Pick your favorite, for read access. I
> do not think there is any argument here :-)
This is a good idea. Even projects that are supposedly using git, like
the Linux kernel, provide a Mercurial mirror, for example, at
http://kernel.org/hg, so clearly even those projects have found some
utility in having both. I expect new committers coming on to only
have to learn one and it's easier to learn Mercurial and focus more
on coding than the source code control system.
> The question now devolves down to those people who commit into the
> system. Do we use Git as the master repository and Mercurial as the
> slave, or do we use Mercurial as the master repository and Git as the
> I propose second that we use Git as the master repository and Mercurial
> as the slave, but allow committers to commit to either and auto-merge
> in both directions.
> I believe this can be done by using Git's superior branch management
> to create a staging branch in Git that is mirrored from Mercurial,
> and then merge that branch into Git's master branch. All automated,
> of course. Several git users, such as corecode and I, would have no
> trouble writing such a script.
> * I am worried that Mercurial's branch management is not good enough
> to cross-merge from git if mercurial is the master. I am also
> worried about our older release branches. Even though we may not
> do a clean initial load into git for non-HEAD branches it should be
> fairly easy to clean things up.
> * We would use commit scripts to trigger the merge operation immediately
> upon a commit to either repository, plus a cron job once an hour to
> catch any lost triggers.
> Only clean merges will auto-commit. A failure will require manual
> intervention using Git, which should be trivial to handle as all the
> data will be in the Git staging and master branches. If the
> git->mercurial merge fails (only possible if a conflicting commit
> is made to git and mercurial simultaniously), then the act of
> resolving the conflict in the git + staging_branch_from_hg will
> auto-correct on the next mirror operation from git to mercurial.
> So no surgery within mercurial will be needed.
All this sounds eminently doable and I'd even volunteer to do write
the scripts or maintain the two repositories.
> Please discuss any or all of the above points or put forth your own
> proposals for discussion. Try to add only new and useful information,
> this isn't a vote thread :-). I do expect far fewer people to post
> in this thread then who voted.
> Our deadline is November 10th. I want to be up and running with the new
> repository as our master by November 15th.