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:b...@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.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
