Richard Lowe writes: > Mike Kupfer wrote: > > Dan Price pointed out to me a week or two ago that merging conflicts is > > less convenient under Mercurial than under Teamware, because once you > > start merging, Mercurial wants you to finish. > > For the sake of my reasoning, why do you want to quit in the middle and > resume? > > I can see why it should be dealt with better, and I can see why it would be > perhaps useful, but I've never intentionally stopped (and quit) mid-merge, > so I agree with Matt that these seems pretty rare (if possibly messy).
I've had to do it fairly often. Sometimes, you'll be faced with a merge barrier created by some big project, and end up with hundreds or thousands of files in conflict, with millions of lines of code to look at. Not pretty, but it does happen. After spending a few hours, you might want to go get something to eat, or see your family again, and then come back later. Another, perhaps more common scenario, is with soliciting help from others. On big projects, it's common for the project gatekeeper to need to merge up periodically with the trunk. Some things go smoothly, but others require someone else to come in and take a look. So, the gatekeeper merges the parts he can, and then leaves the rest in a workspace with permissions set so that others can be invited in to complete the hairy parts. I think if you try doing that with a geographically distributed team, you'll see the problem. > Are we looking at a common thing here, or something that's done rarely? > > I'd really rather not make what I would consider the normal case worse, for > the sake of a corner. I don't think it's really a corner case at all. It happens a lot on big projects. I think it'd be pretty hard to live with a system that requires all merges to be run-to-completion events. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
