Hey guys!
My new issue 3739 is about fixing svn cleanup. Thats good.
But should not ADDITIONALLY also svn ci being fixed, in a way that
svn ci doesn't corrupt the WC? In my reproduction script the svn ci is not
being killed by the user or the operating system. svn ci can take
all action that it wants to do and can exit when it decides to.
The "mv" (with missing "svn" before the mv) does *not* corrupt the WC.
(See http://subversion.tigris.org/issues/show_bug.cgi?id=3739.)
You can read this from the fact, that a "svn st -u" command will
terminate normally (will just report report file a as being missing
and file 1/a as being unknown). It's the "svn ci", that corrupts the WC.
This also can be seen by submitting a "svn st -u" command.
Obviously currently svn ci already notices that something goes wrong
(because it is able to print out error messages). What about the idea
of adding something to that error handler to save the WC? If calling
the svn cleanup code is to fuzzy, what about trying to restore the
WC in the version before the svn ci call? In the end, svn ci is something
like a transaction. In case the transaction fails, should not the WC
be rolled back to the state before the call?
Or (other solution), svn ci could notice *before* starting to change
the WC, that the call will fail (by noticing that file a is missing),
and then exit, before the WC is changed. This would save the rollback
work.
What do you think?
Greetings
Paul.
Received on 2010-10-24 11:01:04 CEST