Source Control system results and discussion

[Edward O'Callaghan]

Pick one and go with it.
Hint: hg +1 ;)

I think another very good reason to use hg over git is that the
community around hg is much more willing to fix bugs and work with
others to improve any short comings of hg.
Thus, if we do have any problems or would like to see things improve
for anything in particular then at least we can get it done/fixed.
P.S. I have worked with both hg and git.

I also would like to add that a good example of a good 'setup' is the
opensolaris project with hg+OpenGrok.
http://opengrok.creo.hu/dragonfly/
http://src.opensolaris.org/source/
http://en.wikipedia.org/wiki/OpenGrok

I don't know if it would help but should I start committing my zfs
port changes so that I have 'C' status?
Nothing is worth commit at the moment though _really_ ..

Thanks,
Edward.


2008/10/28 Peter Avalos <pavalos at theshell.com>:
> 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
>



-- 
All Documents adhered to the ISO/IEC 26300  standard file format for
electronic office documents, such as spreadsheets, charts,
presentations and word processing documents from this email address.
The author does not take responsibility of the recipients inability to
read international standards and who use proprietary products such as
MS Office.
See: http://www.openoffice.org/
Edward O'Callaghan.
--
http://fedoraproject.org/wiki/EdwardOcallaghan
http://moonshine.opn4.org/
http://www.pcbsd.org/