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