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