You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Bob Archer <Bo...@amsi.com> on 2013/10/14 16:28:35 UTC

Reverting an ADD status file after an update tree conflict deletes the file

Perform the following steps...



1.Edit a file in a working copy



2.Delete that file in the repository (with the repo browser)



3.Update your working copy



4.Edit the tree conflict and specify "keep working copy"



5.The edited file now shows as an add



6.Revert the working copy



Observed:



The  file with the add status is deleted.



Expected:



The "add" is removed and the file remains. Basically this is the

behavior you get when you revert a file that you just added. I would

expect reverting an added file to do the same thing whether the file

was marked as add from an update or from just adding it.

---

I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra?

BOb



Re: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Branko Čibej <br...@wandisco.com>.
On 14.10.2013 21:20, Johan Corveleyn wrote:
> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bo...@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@wandisco.com

RE: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Bob Archer <Bo...@amsi.com>.
> On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer <Bo...@amsi.com>
> wrote:
> >> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bo...@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.
> >
> > But, but, shouldn't then a revert, revert back to the pristine of my working
> copy, which is the local file without my modifications? I'm not even seeing
> that, which would somewhat make sense in my head.
> 
> That's indeed pretty strange. I didn't realize that. But even then you would
> have lost your local changes, no?

Indeed. But, then I would have slapped my head and said, "Self (that's what I call myself), it just did what you told it to do." ;) 

Once again though, to repeat, I am 100% used to when reverting an ADD the file isn't removed. My tiny brain doesn't know ADD from ADD with History from a black hole.


> >> 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 +), which seems
> >> to be the case here, svn will just throw away whatever is there,
> >> exactly like when you revert a Modified file.
> >>
> >> There is no "revert only the add, but keep the local mods" operation.
> >
> > Ok, but bottom line... subversion has TRASHED my local changes. This was
> really surprised me, and in a bad way. Granted, I only found this in a test and
> didn't actually lose important modifications.
> >
> 
> You asked it to trash you local changes. That's precisely what revert is for.
> 
> Ok, I think the underlying problem is that svn currently does a lousy job at
> helping users resolve tree conflicts. You're really on your own, and have to
> improvise. Perhaps it's not even possible to resolve this kind of tree conflict
> with standard commands (without moving the modified file aside, and
> moving it back etc). So I can perfectly imagine that you get misled into trying
> 'revert' to get out of the nasty situation. All I can suggest at this time is: never
> revert something if it still contains uncommitted changes. If you're unsure
> what will happen, make a backup copy of your local mods first.

Perhaps. If there were a true life issue I might have said... no, that file was deleted for a reason, so I don't want to re-add it, I want to take my code changes and apply them in the correct new place. So, I'll just revert this "ADD" (which I know from past experience will just keep my local file) and find the correct place to apply these changes... NOOOO... that algorithm I spend 4 hours on is gone... DAMN YOU NEWMAN!!! (I mean subversion!)

BOb


Re: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer <Bo...@amsi.com> wrote:
>> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bo...@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.
>
> But, but, shouldn't then a revert, revert back to the pristine of my working copy, which is the local file without my modifications? I'm not even seeing that, which would somewhat make sense in my head.

That's indeed pretty strange. I didn't realize that. But even then you
would have lost your local changes, no?

>
>>
>> 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 +), which seems to be the case here, svn
>> will just throw away whatever is there, exactly like when you revert a
>> Modified file.
>>
>> There is no "revert only the add, but keep the local mods" operation.
>
> Ok, but bottom line... subversion has TRASHED my local changes. This was really surprised me, and in a bad way. Granted, I only found this in a test and didn't actually lose important modifications.
>

You asked it to trash you local changes. That's precisely what revert is for.

Ok, I think the underlying problem is that svn currently does a lousy
job at helping users resolve tree conflicts. You're really on your
own, and have to improvise. Perhaps it's not even possible to resolve
this kind of tree conflict with standard commands (without moving the
modified file aside, and moving it back etc). So I can perfectly
imagine that you get misled into trying 'revert' to get out of the
nasty situation. All I can suggest at this time is: never revert
something if it still contains uncommitted changes. If you're unsure
what will happen, make a backup copy of your local mods first.

-- 
Johan

RE: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Bob Archer <Bo...@amsi.com>.
> On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bo...@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.

But, but, shouldn't then a revert, revert back to the pristine of my working copy, which is the local file without my modifications? I'm not even seeing that, which would somewhat make sense in my head.

> 
> 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 +), which seems to be the case here, svn
> will just throw away whatever is there, exactly like when you revert a
> Modified file.
> 
> There is no "revert only the add, but keep the local mods" operation.

Ok, but bottom line... subversion has TRASHED my local changes. This was really surprised me, and in a bad way. Granted, I only found this in a test and didn't actually lose important modifications. 

BOb


Re: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer <Bo...@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 +), which seems to
be the case here, svn will just throw away whatever is there, exactly
like when you revert a Modified file.

There is no "revert only the add, but keep the local mods" operation.

-- 
Johan

RE: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Bob Archer <Bo...@amsi.com>.
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.

BOb


From: Bert Huijben [mailto:bert@qqmail.nl]
Sent: Monday, October 14, 2013 3:03 PM
To: Bob Archer; users@subversion.apache.org
Subject: RE: Reverting an ADD status file after an update tree conflict deletes the file

                Hi,

The behavior you see is consistent with reverting a copied file.

When the tree conflict is added your local modification of the modified file was changed into a local copy of the file that used to be there.

Local additions (with no prior history) are kept on revert, but copies are not. The original reason for this is that you still have the file in the repositories history (in case of a copy), while you don't have files with no prior history.

This has the nice side effect that you can revert a ^C'ed merge. If we would keep files that were copied you would have to manually delete the files that were added during the merge.

                Bert

From: Bob Archer [mailto:Bob.Archer@amsi.com]
Sent: maandag 14 oktober 2013 16:29
To: users@subversion.apache.org
Subject: Reverting an ADD status file after an update tree conflict deletes the file


Perform the following steps...



1.Edit a file in a working copy



2.Delete that file in the repository (with the repo browser)



3.Update your working copy



4.Edit the tree conflict and specify "keep working copy"



5.The edited file now shows as an add



6.Revert the working copy



Observed:



The  file with the add status is deleted.



Expected:



The "add" is removed and the file remains. Basically this is the

behavior you get when you revert a file that you just added. I would

expect reverting an added file to do the same thing whether the file

was marked as add from an update or from just adding it.

---

I reported this on the TSVN list and got a response of that how svn does it. Doesn't this go against the do no harm mantra?

BOb



RE: Reverting an ADD status file after an update tree conflict deletes the file

Posted by Bert Huijben <be...@qqmail.nl>.
                Hi,

 

The behavior you see is consistent with reverting a copied file.

 

When the tree conflict is added your local modification of the modified file
was changed into a local copy of the file that used to be there.

 

Local additions (with no prior history) are kept on revert, but copies are
not. The original reason for this is that you still have the file in the
repositories history (in case of a copy), while you don't have files with no
prior history.

 

This has the nice side effect that you can revert a ^C'ed merge. If we would
keep files that were copied you would have to manually delete the files that
were added during the merge.

 

                Bert

 

From: Bob Archer [mailto:Bob.Archer@amsi.com] 
Sent: maandag 14 oktober 2013 16:29
To: users@subversion.apache.org
Subject: Reverting an ADD status file after an update tree conflict deletes
the file

 

Perform the following steps.

 

1.Edit a file in a working copy

 

2.Delete that file in the repository (with the repo browser)

 

3.Update your working copy

 

4.Edit the tree conflict and specify "keep working copy"

 

5.The edited file now shows as an add

 

6.Revert the working copy

 

Observed:

 

The  file with the add status is deleted.

 

Expected:

 

The "add" is removed and the file remains. Basically this is the 

behavior you get when you revert a file that you just added. I would 

expect reverting an added file to do the same thing whether the file 

was marked as add from an update or from just adding it.

 

---

 

I reported this on the TSVN list and got a response of that how svn does it.
Doesn't this go against the do no harm mantra?

 

BOb