Mark Phippard wrote:
> On Wed, Oct 29, 2008 at 9:38 PM, Neels J. Hofmeyr <neels_at_elego.de> wrote:
>> Just re-iterating: When you run Revert, I'd expect it to become the reverted
>> state before the tree-conflict, i.e. the old base without local mods. Which
>> is kind of not what sentient users might expect at all.
>
> For a user to want or expect that behavior would seem that they would
> have to just ignore what an update command does. If I run update does
> it update or not? If it does, then the file ought to reflect the
> state of the repository -- unversioned. Of course perhaps we need to
> invent a new "state" for this scenario, but if we have to choose from
> our existing states I think unversioned is the one that reflects the
> reality of the situation. It also puts the working copy in the best
> place to resolve the conflict as the user can run svn add or "rm" to
> put the WC into the desired state. In this scenario, it probably
> makes sense for the parent folder to be in the tree conflict state?
>
A quick response on this:
You are right, the behaviour you are describing is definitely wrong. Do you
still have the commands to reproduce the error?
For fixing it, I'd like to note: It feels wrong to me to ever unversion a
file that has local mods. Instead of creating a pitfall where people lose
their local changes when they forget to re-add a file that was perfectly
versioned Since Forever, I would prefer keeping the file versioned and
requiring an `svn rm' by the user if she doesn't want it anymore.
An exception would be the `move' case, where we successfully auto-moved the
local mods to the new file, if we are ever going to do that. Then I'd
happily agree with unversioning and removing the old file automatically. But
in all current tree-conflict cases I can think of, I emphatically wouldn't.
~Neels
Received on 2008-10-30 07:05:19 CET