Re: Some Defects

"Mark Watts" <mwatts3@stny.rr.com> writes:

> 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.

Unknown? The status command should work. The merge command lists the
items it affects. Those should be enough to allow you to determine the
working copy 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.

Not quite. If the working copy file had local changes before the
merge then running revert will undo both the merge and the local
changes.

> 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?

There is no general way to undo a merge automatically. If there were
no local modifications prior to the merge, and if no conflicts created
during the merge, then the command

  svn merge -rX:Y URL wc

could be reversed using

  svn merge -rY:X URL wc

There is one slight disadvantage to this, if any of the merged files
end up without local changes then the text-base timestamps recorded in
the entries file will not identify those files as unmodifed. Until
the timestamp gets updated Subversion will fall back to a byte
comparison of file and text-base.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org