Source Control system results and discussion

[Peter Avalos]

On Mon, Oct 27, 2008 at 08:49:26PM -0400, Joe Talbott wrote:
> 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?
> > 

Git as the master.

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

Ugh...Yeh I threw up in my mouth a little reading what Matt wrote.  I
think we need to pick one and go with it.

There's administrative and policy decisions that need to be made when we
do decide on a system.  Here's a quick brainstorm:

-Distribution of src
-contrib/crypto
-branching policy
-import into base src or use a package

I'm sure more things will surface, but I think we need to solidify
which one it's going to be first.  I'm still suggesting we go with git
and make a hg repo available for read-only access.

I guess what I'm really trying to say is...Let's decide on a system so
we can move on and make the policy decisions we'll need to make with a
new system.

--Peter
Attachment:
pgp00002.pgp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pgp00002.pgp
Type: application/octet-stream
Size: 197 bytes
Desc: "Description: PGP signature"
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20081027/26adffb6/attachment-0020.obj>