On 14.10.2013 21:20, Johan Corveleyn wrote:
> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>> Bert,
>>
>>
>>
>> But, this isn’t a merge it is an update. If I revert the add I lose all the
>> changes I made in step 1 of my steps below. I might have made a few hundred
>> changes. Granted, I probably shouldn’t do the revert without copying the
>> file off somewhere… but those local modifications I made are NOWHERE in this
>> case and can’t be recovered if my local copy of the file is deleted.
>>
> But, but ... isn't 'revert' always a lossy operation? If you revert a
> locally modified file you also lose your local modifications.
>
> OK, if you revert a normal 'add', svn will keep the local file. But as
> Bert said, if you revert an 'add with history' (A +),
I agree with Bob that this is not good behaviour. It's not a local add,
it's "local edit, incoming delete upon update". It may have been
resolved to an "add with history" but the "history" in this case is just
a previous version of the same file; effectively, the file was
resurrected. Throwing away local modifications like this is not nice.
That said, it's not exactly a bug, either. The only reasonable solution
I can think of is to revert to the exact state before the update, which
implies that we'd have to remember that state, local mods and all. In
other words, we'd have to implement working copy checkpoints, a.k.a.
local commits.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-10-14 21:34:27 CEST