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.
> 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.
> 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
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).
Received on 2010-08-11 13:14:27 CEST