[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: lose unversioned data with revert

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 1 Mar 2012 09:51:39 +0000 (GMT)

Neels J Hofmeyr wrote:
> Stefan Sperling wrote:
>> On Wed, Feb 29, 2012 at 04:07:10PM +0100, Neels J Hofmeyr wrote:
>>> My impression was that svn tries to leave unversioned data around until
>>> the user takes care of it (as with 'svn delete dir'). That's
>>> what I thought obstructed states are for.
>> Revert is a bit of a fine line. It is a command that is supposed to
>> throw away local changes. So by definition is it disruptive and
>> dangerous.
>> However, I agree with the sentiment that revert should not delete
>> unversioned data from disk.
> What stsp said

Philip Martin wrote:

> Julian Foad <julianfoad_at_btopenworld.com> writes:
>> Philip Martin wrote:
>>> Neels J Hofmeyr <neels_at_elego.de> writes:
>>>>   An unversioned file should never be killed, right?
>>> You are explicitly reverting x, are you saying revert should fail?  My
>>> first instinct is that revert is doing the right thing.
>>>   What about this:
>>> svn rm x        # delete a versioned dir
>>> echo data > x    # add an unversioned file
>>> svn revert x    # directory restored
> Another example:
> svn rm x            # delete a versioned file
> svn mkdir x          # add a versioned dir
> echo data >  x/f    # unversioned data
> svn revert -R x      # versioned file restored, unversioned data removed

All we need to do is refer to our high level spec for 'revert'.
[Looking... where did we put it... oh, never mind.]

Now, I'm not saying I think we need to change anything, but let's just explore the idea a bit.

  What kinds of 'unversioned data' exactly?
    - uncommitted text changes in a normal versioned file?
      (no, we all agree on that one)
    - a file on disk where 'working tree' expects a dir?
    - a file on disk where 'working tree' expects nothing?
    - unversioned files/dirs inside a normal versioned dir?
    - ... and so on.

  What should 'revert' do in those cases?

  What should the user do when they need to revert those cases?

The idea is that 'revert' should notice that in order to restore the versioned item onto
 disk it would have to delete 'unversioned data'.  And then let's say for now that it should
bail out, complaining, and if the user really wants it to proceed they could supply a 'force' switch.

So how would we define 'unversioned data' exactly?  Let's try, for starters, "any node on disk that's the wrong kind, or is unexpected, compared with the 'working tree'".  Tabulated:

  St Actual   Working   Base   Should revert?
     file     file      file   y
  ~  dir      file      file   No?
  !  none     file      file   y
  ~  file     dir       file   No?
     dir      dir       file   y
  !  none     dir       file   y
  ?  file     none      file   No?*
  ?  dir      none      file   No?
     none     none      file   y
     file     file      dir    y
  ~  dir      file      dir    No?
  !  none     file      dir    y
  ~  file     dir       dir    No?
     dir      dir       dir    y
  !  none     dir       dir    y
  ?  file     none      dir    No?
  ?  dir      none      dir    No?*
     none     none      dir    y
     file     file      none   y
  ~  dir      file      none   No?
  !  none     file      none   y
  ~  file     dir       none   No?
     dir      dir       none   y
  !  none     dir       none   y
  ?  file     none      none   No?
  ?  dir      none      none   No?
     none     none      none   y

unversioned nodes inside versioned dir ... ?

The '!' status: there is no node on disk where one is expected.
  These we should (and do, AFAIK) revert quietly, in the same way
  as if the expected node was present on disk.

The '~' status: there is a node on disk and it is of the wrong kind.
  (kind != none) && (actual-kind != working-kind) && (working-kind != none)
  We could say these cases would lose 'unversioned data'.

The '?' status: there is a node on disk where none is expected.
  We could say these cases would lose 'unversioned data'.
  * The cases marked with '*' couldbe the result of "rm --keep-local",
    so we might be less willing for 'revert' to complain about these.

Neels, does that help clarify your thoughts about what kinds of 'unversioned data' 'revert' should refuse to revert?

- Julian
Received on 2012-03-01 10:52:16 CET

This is an archived mail posted to the Subversion Dev mailing list.