Re: "svn resolve" Leaves Temporary Files in WC When More Than One Conflict for a File is Present

[Julian Foad <ju...@btopenworld.com>]

On Thu, 2008-07-10 at 15:47 -0400, Mark Phippard wrote:
> On Thu, Jul 10, 2008 at 3:33 PM, Jeremy Whitlock <jc...@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
> them?
> 
> 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
> files.

I am taking note of this thread and hope to improve the situation in
some of these regards along with tree conflict detection.

- Julian



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