AW: should be neccessary to call svn cleanup only in case a command got killed, not in case of an error
Who agrees that svn ci should also be fixed and that this is worth
filing an issue?
> -----Ursprüngliche Nachricht-----
> Von: Paul Maier [mailto:svn-user_at_web.de]
> Gesendet: Sonntag, 24. Oktober 2010 11:00
> An: 'users_at_subversion.apache.org'
> Betreff: should be neccessary to call svn cleanup only in
> case a command got killed, not in case of an error
> 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
> What do you think?
Received on 2010-10-26 01:54:50 CEST
This is an archived mail posted to the Subversion Users