dist-hg proof-of-concept ready for use

[Dan Williams]

On Sun, 2006-11-12 at 23:22 -0500, Jesse Keating wrote:
> On Sunday 12 November 2006 23:15, Christopher Blizzard wrote:
> > I was also talking to Dan about this tonight.  He likes git more because
> > it apparently has better merge behaviour?  I guess the version they were
> > using before would just dump stack traces when there were problems.  I
> > would love to hear more real-world data like that.
> 
> I haven't tried to do a merge yet, I really should (:  This page describes 
> some of the merge stuff:
> 
> http://www.selenic.com/mercurial/wiki/index.cgi/MergeProgram

My memory is hazy, but we used Mercurial for about a month back in May.

I think it was just frustrating because the behavior was so different
from CVS and misunderstanding the philosophy was part of our problem.
But in very fast-paced development, when you want to push updates pretty
frequently in a more "centralized" manner, and other people are pushing
updates pretty frequently too, you end up spending 15 - 25% of your time
just fighting mercurial's merge/branch strategy if you don't have much
experience with it.

It kept complaining that pushing would create a new branch on the server
and appeared to have a "assume you want to branch by default" strategy
when that is almost _never_ the case for what we were doing.  This was
usually because we completely forgot to 'hg merge', the magic missing
step.  But if you forget the merge step, hg assumes that you actually
_do_ want to make new branch when you push and that you were only
looking at somebody else's changes and didn't want them anyway, because
if you did, you obviously would have remembered to 'hg merge'.  And
doing command aliasing is just plain broken.

Part of the problem was that mercurial (at the time) had _NO_ error
reporting whatsoever that any mortal could understand.  While in git you
can't figure out which damn tool you're supposed to use out of the 150
that get installed, with mercurial you couldn't for the life of you
decipher what the error messages (or tracebacks!) meant or how to go
about fixing the problem.  Maybe that's fixed now.  Examples of this
were that, while running mercurial in a chroot, permissions problems in
the chroot caused the hg client to completely vomit with no helpful
information about WTF the problem was at all.

In summary, while the behavior of mercurial isn't _that_ much different
from stuff like git, it's behavior was just a little too far out in left
field to be easily understood by those of use using it for OLPC
development back in May.  Git's a more comfortable medium somewhere
between SVN and closer to mercurial in philosophy but more pragmatic.

So if mercurial _is_ chosen as the successor to CVS for Fedora's
infrastructure, my greatest hope is somebody will write up some
documentation that helps poor CVS users understand the problems they
might face with branching & merging and how to work those out without
throwing something out the window or having to jump on #fedora-devel to
ask.

Cheers,
Dan

> --
> Fedora-maintainers mailing list
> Fedora-maintainers at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-maintainers