[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 10 Jul 2008 21:49:53 +0100

On Thu, 2008-07-10 at 15:47 -0400, Mark Phippard wrote:
> 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
> 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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-10 22:50:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.