Julian Foad wrote on Wed, Aug 11, 2010 at 11:33:49 +0100: > On Wed, 2010-08-11, Stefan Sperling wrote: > > The BRANCH-README suggest that we add an interface like > > 'svn propedit --revprop pname pval2 --old-value=pval'. > > I don't think there is a valid use case for non-atomic revprop changes. > > Why not just make all revprop changes atomic by default if the client > > and server are both >= 1.7? Any propset/propedit operation could > > transparently retrieve the old value before trying to set the new value. > > It makes sense for propEDIT to ensure that the old value it got is still > current when it sets the new value.
It already does this, propedit-cmd.c calls svn_client_revprop_set2(), which I have patched on the branch to be atomic if the server supports it (and is already on trunk "best approximation of atomic" for older servers). > It would be silly for that to be a > command-line option. It should always do it. > (see above) > But for a propSET command, the old value that the user was looking at > before performing the set is not something that the command itself can > get. There's no point in the command retrieving the "current" value at > the time the propSET command is run, because that's not necessarily the > value the user was looking at - it's already too late. Yep. > There is a case > for this command taking the expected old value from the user, not that a > command-line user is likely to provide it, but a script might. The API > behind it should certainly take this option so that GUIs etc. can use it > in implementing their own propedit-like functionality via the propset > API. > Yes. I was wondering whether to extend the client API to use the atomic RA API, but then I discovered it already was doing "best approximation of atomicity" so I went ahead and patched it up. This reduces the scope of the BRANCH-README item stsp quoted to just "Should propset-cmd.c expose this flag?" --- which, re hwright's question, is one of the trivial items that I won't hold reintegrating the branch on. > - Julian > > The _client API patches are r983234 and r983237 (both on the branch).
