DragonFly kernel List (threaded) for 2008-10
DragonFly BSD
DragonFly kernel List (threaded) for 2008-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Source Control system results and discussion


From: Joe Talbott <josepht@xxxxxxxxxx>
Date: Mon, 27 Oct 2008 20:49:26 -0400
Mail-followup-to: Matthew Dillon <dillon@apollo.backplane.com>, kernel@crater.dragonflybsd.org

On Mon, Oct 27, 2008 at 05:15:33PM -0700, Matthew Dillon wrote:
>  
>     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.

It seems to me that allowing commits via both Git and Mercurial is
going to be a ton of administrative work if problems arise.  Being
that we are a small group do we want to maintain both?

Joe



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]