On Thu, Jul 10, 2008 at 3:33 PM, Jeremy Whitlock <jcscoobyrs_at_gmail.com> wrote:
>> Meaning, if there are two conflicts in a file (and maybe a third in its
>> properties), you can mark individually any one of the three as resolved?
>> This isn't possible (afaik).
> Yeah. That's what I'm talking about, or at least be able to resolve
> the whole file, which happens now, and remove all temporary files
> associated with this file's conflict(s).
>> IIUC, 'svn resolve' should remove the .rN/.rN+1/.mine files, like
>> 'resolved' always did. If you need someone to validate this specific
>> scenario, please provide a reproduction script. :)
> Actually, you got it. Basically the resolve(d) works as designed but
> leaving left over temporary files confuses people and causes them to
> think Subversion's broken. Ideally, it'd be great to mark each
> conflict block as resolved individually or at least remove all
> temporary files when you resolve a file, no matter how many there are.
I think in general we also are inconsistent in this area of conflicts.
I recall at one point we decided once merge produces an unresolved
conflict it should not continue to the next revision range. For
example, if you just run svn merge with no revision args, and it needs
to merge multiple ranges, it will end after any range with unresolved
conflicts. But other merge options we added such as naming multiple
ranges manually does not.
While I do not love the idea of ending the merge process early, this
was one of the reasons it did it. So that multiple sets of conflict
files are not generated. After all, how does someone really resolve
Of course a related problem would be if your working copy already has
unresolved conflicts in it, then that would imply merge ought to not
run at all as it might wind up needing to merge into one of these
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-10 21:47:54 CEST