Apache OpenOffice (AOO) Bugzilla – Issue 76678
cwsresync does not detect/alert when a file is removed in MWS, but changed on CWS
Last modified: 2013-08-07 15:34:52 UTC
With the integration of CWS hedaburemove01, which moved a lot of files in CVS, it became evident that cwsresync leaves you alone if you resync to a new milestone, and a file which you changed in your CWS has been removed in MWS. For details, see Bjoern's mail here: http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=19725 Since cwsanalyze is able to detect the mentioned change, and since cwsresync in turn is able to detect (and alert about) the contrary case (a file being removed in CWS, but changed in MWS), cwsresync should definitely warn the user here. Setting this to P2, since various reports from developers indicate that a lotta people have a lotta trouble with the current behavior.
targeting to "DevTools"
Some background information (from what I know about that - I am not the code owner here): cwsanalyze easily detects files removed on MWS and changed in CWS, cwsresync detects when a file has been changed on MWS and removed on CWS. The reason is in how both tools work. cwsanalyze takes the diff from a childworkspace and merges that onto the master. In your case it finds a diff in a header file, tries to apply that to the HEAD revision, and fails, because the file has been removed head. So you get that information 'for free'. cwsresync OTOH takes the diff between two master milestones and merges that diff to your CWS branch. Here the 'diff' is a removal, which can been applied to your branch without problems. In order to emit an warning we would have to explicitly ask cvs about what happened on the CWS branch, i.e. we would need an additional cvs query. This has not been implemeted because of performance reasons (cwsresync already is slow enough). Of course I understand your problem. In the light of 'hedaburemove01' it perhaps has to be reconsidered whether we choose the right compromise between speed and security. Nevertheless I do not think this issue gets fixed soon. As you probably know we are preparing a change from CVS to some more modern SCM. During this change we have to adapt all cws tools anyway. I therefore doubt that this issue gets worked on before this bigger tooling rework. But, yes, when doing that rework we should have this request in mind.
That's absolutely understandable. But in this case we should think about making cwsanalyze mandatory or at least warn all developers and explain the situation.
First, Rüdigers assessment of the situation is completely on the spot. With the new PCVSLib implementation of "cwsresync" we'll get a factor of 20 or so improvement in the "cwsresync -m" step so I think we can trade here some speed for safety. Essentially we would need annother rdiff command over the module (that's the "get changed files" part which is printed during cwsresync. Since this is a completely remote command (executed only on the server), and we can now use the same CVS server instance on the remote side I guess it will not cost much, because all the files are probably still in the cache on the server side (from the first rdiff command). The amount of information transfered is neglible. I'll implement that in the new cwsresync command.
Ah, the current version of the new cwsresync.pl already contains this check, and without any additional cost at all :-).
Verified on CWS cvsprot01. You now get an alert A <filename>: has been removed on MWS but is changed on CWS. Will remove file. Please check!
*** Issue 80207 has been marked as a duplicate of this issue. ***
Close issue.