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.
On Tue, 28 Dec 2004 08:25:53 +0000 (UTC), "Oliver Giesen" <ogware at gmx.net> wrote: >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. There is, however, a slight problem here: If a developer has a number of changes in his files that he *has* tested and is now ready to commit them he must first do a cvs update to make sure his files are revision wise at the top of the tree. So he makes the update and a bunch of *other* edits gets merged into his files. The files are now for sure marked "result of merge", but there is no simple way to locate the merges that were done to his files by the update. Diff will not work because these changes are not diffable changes with respect to the CVS repository, only his own (already verified) edits are. So he has no tool to find and verify the *other* edits and must rely on the other developers having written code that is compatible with his own new changes.... It would be nice to have a possibility to *undo* a cvs update thus bringing back the file states to what they were in just before the update when they contained only the developer's own edits on top of the revision he started out with. It would not be a great tool, but it would make it possible for the developer to recreate his files and revision state so he can at least create a branch at that point and store his edits into that branch.... Maybe there is just such a function available that makes use of the #-marked files that get created during updates??? /Bo (Bo Berglund, developer in Sweden)