> -----Original Message-----
> From: sussman@collab.net [mailto:sussman@collab.net]
> Sent: Friday, May 30, 2003 14:15
> To: dev@subversion.tigris.org
>
> Philip Martin <philip@codematters.co.uk> writes:
>
> > > 2. If for some reason the merge fails and you do a 'svn
> revert -R
> > > .' on the tree to put everything back, files that have
> been added as
> > > part of the merge are not deleted.
> >
> > That is how revert is intended to work.
>
> Correct.
>
> II create a new file, and 'svn add' it. Then I change my
> mind; I don't want to put it under version control after
> all. When I run 'svn revert', it removes the scheduling
> only. It would be awful if it deleted the file -- the data
> would be gone forever.
OK. I can see that and agree.
However, I have a new question. When a merge fails, as it did in this
situation, it can leave the working copy in an unknown state. I used 'svn
revert' as the means to try and bring the working copy back to a known state
and from what you are both saying it did so as far as the subversion
meta-data in '.svn' directories was concerned AND as far as reverting
modified or deleted files to the state they were at prior to the merge.
However, because the add was done and then unscheduled the revert didn't
really 'undo' the merge completely. Right? What is the standard way to
correct this situation?
-Thanks
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 31 00:32:48 2003