Source Control system results and discussion

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

    Ok, the results again.  I added a generic comment gleaned from IRC
    and email postings on the main difference, which may or may not be
    correct (discussion welcome).


    Git (19)	w/ heavier weight of committers

	Superior branch management.

    Mercurial (19)	w/ lighter weight of committers

	More convenient and easy-to-use commands.

    Other (2)

	"Oh God"

 
    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 :-)

    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.


    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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>