Den tis 29 juni 2021 kl 12:33 skrev Julian Foad <julianf...@apache.org>:
> Daniel Shahaf wrote: > > Julian Foad wrote on Fri, Jun 25, 2021 at 14:27:30 +0100: > > > Now filed as: https://issues.apache.org/jira/browse/SVN-4877 > > > > "Now"? The issue is a month old. > > You're absolutely right! That's when I was made aware this issue had come > up again. First I noticed we had not previously filed an issue, so I > started by filing it as #4877, and started drafting this email. With life > getting in the way, it has taken me until now (ahem, I mean June 25th) to > re-check everything and put this email together with the clearest > explanation I could. > > Thank you for taking another look at this. > > There could be two angles to view this issue. One angle is looking at the > specifics of why WD's replicator wants different behaviour, which I will go > into further below. > > Another angle could be looking from a software design point of view and > saying of course code like this should clean up like this. I am hopeful > that someone may be able to see it from this angle and say of course this > change is right in principle, and maybe point out if I got the specifics > right or missed something. > This was my reflection when I read the first mail - although I don't yet know enough of the specifics of Subversion to say if it is reasonable. My philosophy is that whenever something fails, the code should try to roll back as much as possible so the caller could retry. For example if I fopen() two files and the second fail, I tend to close the first one before returning an error message. Then the caller can figure out why the second failed - potentially recovering and retrying. > > > PROPOSED FIX > > > > > > My proposed fix is to unlock the lock when exiting that code section, > no matter whether successful or throwing an error. > > > > > > Pseudo-Python: > > > > > > try: > > > 1. Get a write handle on the proto revision file. > > > 2. Complete the construction of the proto-rev file. > > > 3. Move the finished rev file into place. > catch: set a flag to abort after finally (but maybe that was implict) > > > finally: > > > 4. Unlock the proto-rev file. > > > 5. Continue with the rest of the commit finalization. > > > > > > > Why would this be correct? Why would this have no downside? > > Would it be easier to see from this angle: that would make the behaviour > for a re-try within one calling process equivalent to the existing > behaviour that would occur if the FSFS machine restarts and a new calling > process re-tries. Could there be other parts where "state" is set in someway that makes it impossible to restart with the same calling process? Kind regards, Daniel Sahlberg
