On Fri, Nov 22, 2002 at 12:23:56PM -0500, MacMunn, Robert wrote: > Thanks. Looks like merges must be difficult in CVS. A lot of manual work.
Only when both new versions have changed the same area of the file. That is, if I edit line 100 and you edit line 120, there won't be a conflict. But if we both edit line 110, there will be. That's the theory. In practice, here is a partial list of things that can cause *lots* of conflicts: 1. Line-ending differences: your file has UNIX line endings; mine has Windows line endings (as if! :-). Then CVS will see *every* line as different, so the whole file will be one huge conflict. 2. If one (or both) people reformat the code -- run it through a code beautifier, change spaces to tabs or vice-versa, go through by hand and nicely line up abundant end-of-line comments, or whatever. Even though those changes don't have any effect on the program's behaviour, they're still changes as far as CVS is concerned, so they'll conflict with any other change (whether significant or also trivial) that another person makes in the same region of the file. 3. If someone wraps a block of code in an "if" statement, say, they'll indent it all an extra level. Again, the indentation change is a non-event as far as the compiler's concerned, but CVS can't tell that. 4. CVS keywords, especially $Log$. 5. Configuration files that need to be customized for each instance of the system (different sandboxes, different servers, etc.) All the routine per-instance customizations often conflict with substantive changes. XML seems to be particularly bad for this, I suspect because there's so much redundancy that the merge algorithm can get confused more easily than with other file types. Some of those situations should just be avoided: (1); $Log$; possibly other $Xxx$'s, though $Id$ can be useful enough to be worth putting up with the resulting merge conflicts. Others -- (2) and especially (3) -- are sometimes necessary, so the trick is to do them in such a way as to minimize the pain. If you know you're going to be making massive, trivial changes, like beautifying the whole project, get other people to commit their changes and go to lunch. Then you update, do your thing, and commit. That way they won't have done any work, so there won't be any conflicts. Things like changing the indentation on a large block of code are harder to schedule -- you do it based on need, not on "would be an improvement" -- so the resulting conflicts just kind have to be lived with. (5) can be greatly improved by going to a template-based approach. For the project I'm currently on, I whipped something up in Perl to do autoconf-like macro substitutions on the XML config files. If all the per-instance customizations -- host names, port numbers, etc. -- are done by that Perl script, and only the uncustomized templates are stored in CVS, the many pointless conflicts will go away, and the only remaining conflicts will be between groups of *substantive* changes. A special case of (2) is files that are written with the aid of smart tools -- XML editors, IDE's, and the like. Then you don't necessarily have control over the precise formatting; the tool might change things in ways you didn't expect. Similarly filled text -- add a word, and the rest of the paragraph might get reflowed. Not much that can be done about those cases, unless you (and your colleagues) are willing to forego the spiffy tools... In summary, merge conflicts are indeed a problem. Worse in some situations than in others, but usually manageable, by which I mean, reducible to the level of annoyance rather than major productivity drain. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED] | | / Just Say No to the "faceless cannonfodder" stereotype. - http://www.ainurin.net/ (an Orc site) _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs