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.
> > >> BTW, I also noticed that the temporary files created on the server by >> the -n option are never cleaned, wile the files created without the >> option are cleaned ! It seems that when diff3 returns an error, the >> temporary files are not cleaned ! > > > Possible, or it could be the -n suppressing disk changes. Not sure. > Again, this is all just speculation. I presume you don't have this > problem when you don't use the -n, correct? Indeed, when the merge is performed without the -n the server deletes the temporary files and it is visible on the server side of the log ( unlink traces ). However in the file rcscmds.cpp, in function RCS_merge(), when an error is returned by diff3, the cleanup is not perormed. So it looks like a basic implementation problem :). > From a procedural standpoint, I'm not sure I understand the necessity >of doing the dry run merge command. What does that do for you? I >always review my merges, but it's in this order: > >commit all changes >update to merge destination >perform merge >review all diffs / conflicts >IF like_results != true, cvs update -C to reset and start over >ELSE commit -> Done. OK let me explain why it is important to do a preview, at least from my point of view. The fact that the output of the dry run is quite easy to process, makes it easy to write a perl script that would : 1/ perform a merge preview 2/ identify the files that are conflicting 3/ trace out who/why modified the file in order (using viewcvs database for instance) This makes the merge process easier and faster especially if there is a large number of commits performed by a certain amount of developpers. As the person that perfoms the merge is not always the one that commited the changes, it helps him to identify the conflictual changes and to check conflicts with the commiters. Further, once the conflictual files/versions are identified it is also easy to automate the conflict resolve processing by scrpting the invocation of a visual merger (kdiff3/xxdiff). Now some people migth find this automation usfull others might find it completly dumb, it depends on the way you're working. However the -n option on update commoand is documented and should work, and it basically don't :(. So should this be fixed or not, I can't decide. However if the command accepts the -n option and that the option is not working, my point of view is that this issue should at least be tracked on the BTS or documented in the release notes. I don't have any experience with the cvsnt source code, but I'm willing to invesitgate the pb. However if the project devteam cheks this out, I'm quite sure that the resolution could be much faster ! Best Regards, Zlatko