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.arc...@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
On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@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
On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@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
On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer bob.arc...@amsi.com wrote: On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@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
On 14.10.2013 21:20, Johan Corveleyn wrote: On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@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. br...@wandisco.com
RE: Reverting an ADD status file after an update tree conflict deletes the file
On Mon, Oct 14, 2013 at 9:26 PM, Bob Archer bob.arc...@amsi.com wrote: On Mon, Oct 14, 2013 at 9:08 PM, Bob Archer bob.arc...@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... N... that algorithm I spend 4 hours on is gone... DAMN YOU NEWMAN!!! (I mean subversion!) BOb
