Source Control system results and discussion
Matthew Dillon
dillon at apollo.backplane.com
Mon Oct 27 17:18:15 PDT 2008
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 at backplane.com>
More information about the Kernel
mailing list