Source Control system results and discussion

[Jeffrey Hsu]

  >  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
  >  slave?
  > 
  >  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.