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/

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_wandisco.com]
> Sent: woensdag 4 februari 2015 10:23
> To: dev_at_subversion.apache.org
> 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, rhuijben_at_apache.org 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
Received on 2015-02-04 11:03:09 CET