Hello everybody! Who agrees that svn ci should also be fixed and that this is worth filing an issue?
Paul > -----Ursprüngliche Nachricht----- > Von: Paul Maier [mailto:svn-u...@web.de] > Gesendet: Sonntag, 24. Oktober 2010 11:00 > An: 'users@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 > work. > > What do you think? > > Greetings > Paul. > >
