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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
