> 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... NOOOO... that algorithm I spend 4 hours on is gone... DAMN YOU NEWMAN!!! (I mean subversion!) BOb
