> -----Original Message-----
> From: Branko Čibej [mailto:[email protected]]
> Sent: woensdag 4 februari 2015 10:23
> To: [email protected]
> Subject: Re: svn commit: r1657026 - in /subversion/trunk/subversion:
> bindings/javahl/native/ bindings/javahl/src/org/apache/subversion/javahl/
> include/ libsvn_client/ libsvn_wc/ svn/ tests/libsvn_wc/
>
> On 04.02.2015 09:36, [email protected] wrote:
> > Author: rhuijben
> > Date: Wed Feb 4 08:36:20 2015
> > New Revision: 1657026
> >
> > URL: http://svn.apache.org/r1657026
> > Log:
> > As we are revving svn_client_revert() for 1.9 anyway, now is the time to
> > give it a 'metadata_only' flag, like we have on copy and move.
>
> I understand the case for a metadata-only copy and/or move.
> What's the use case for doing a metadata-only revert?
In my particular case:
Users automatically replacing files like .dll's (shared libraries) and .xls
document files.
The delete is automatically handled and properly recorded as a delete in
Subversion. (The --keep-local flag is essentially delete's metadata only, as it
allows deleting without error)
But then the file is replaced, by some outside process. The current worst case
is the NuGet Visual Studio addin, that just tells me that the user does things
(who doesn't) and sometimes blocks access.
The user goes on with his work and locks the file... (opens excel, starts
debugging, whatever)
Now the user wants to commit his workspace, but explicitly doesn't want to
record the delete + add as a delete, but as a normal file update.
To change the in-wc state to a normal update I have to call revert... But that
currently requires replacing the in-wc file with the old version.
(And moving around the file to keep the copy has all those other nice side
effects)
This patch allows handling this workflow with a single call to revert, that
typically can't fail unless another Subversion client changes the same wc at
the same time.
TortoiseSVN has a similar workflow, somewhere in its context menus.
Bert
