On Thu, 18 Aug 2011 20:46:51 +0000, Stefan Sperling wrote:
...
> > Actually I think these are better handled by throwing away the merge
> > results and doing the renames/removes on the respective branches, then
> > redo the merge.
>
> The above is only for "add vs. add" situations.
> Scenarios involving renames are different.
I meant when I get an add/add conflict on unrelated directories
(or files), I'd undo the merge, rename one of the directories in the
respective branch and retry the merge. Offhand, I wouldn't know where
subversion would place the unrelated versions of the directories in the
sandbox, nor how I could tell it that I want one of those kept in the
merge result (with same or different name).
> > I tend to feel uneasy in these interactive conflict resolutions.
>
> What makes you feel uneasy about it?
I'm used to manual merges, which means its always (p) with me. Which
unfortunately does not work quite well with properties, as far I
remember. (And (e) gives me 'EDITOR not set' even though it is
offered.) One thing that would be helpful is (!): Run a shell.
And in the interactive mode it's one file after another; I can't
compile well in between. (I was lucky enough not to have actual
tree conflicts yet.)
> Note that, ideally, this menu could be recalled offline, after the
> merge/update has completed with all conflicts postponed.
> So you'd have all the time in the world to figure out your answer,
> if that's what worrying you.
The problem is more like it is another tool which you hopefully never
need, yet need to know well if you do.
Just the display of what has been done so far ('dir from branch will
commit as newdir') is going to be interesting.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2011-08-19 12:21:59 CEST