Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Gabriel Genellina wrote: > I want that any time a merge is needed, it's marked as a conflict. > I don't want any automatic merges, no matter how trivial they would > be; I want all merges resolved by the developers. That's how it should be anyway. Are you aware that merging is a pure client-side operation? The changes produced by the merge have to be explicitly committed before they get incorporated into the repository. Now take that and the fact that no single file should ever be committed without prior review regardless of how it came into committable state. And if you're just out for eye-candy, that's already there. If you do a status on your files or view them in a GUI frontend like WinCvs there will be a clear note saying "Result of merge". Forcing a conflict status if there is none is just additional and unnecessary sugar on top of that IMO. > In other words, if > I modify a file in my sandbox and another user commited a new > revision, when I do a cvs update I want it to be flagged as a > conflict, even if the modified lines are far apart. (You may think > it's a bit paranoic -maybe- but we have good reasons to review all > changes before merge) No, it's not paranoid at all. It is a basic principle and as such should be common practice. The measures you suggest are only necessary if it isn't and in that case you've already got a bigger problem anyway. No change should ever be committed without review. I cannot stress this enough. Yes, it can be tedious to go through all files before commit but it's usually far more tedious to have to remove all that crap once it has found its way into the repository. Merges are often the smallest problem in this context actually. My 2c. Cheers, -- Oliver ---- ------------------ JID: ogiesen at jabber.org ICQ: 18777742 (http://wwp.icq.com/18777742)