> > I would think the merge in step 4) would communicate to the server that
> > the deletion of branch2/file.txt was due to a merge from branch1/, so a
> > merge in the opposite direction (branch2/->branch1/) should not trigger
> > a tree conflict. Is this possible?
>
> No, unfortunately it's not possible.
>
> The revisions you committed during steps 3) and 4) (let's call them
> rX and rY) are two distinct identifiers for the same semantic change
> which says "delete file.txt". But Subversion doesn't know that.
> It only knows revision numbers, and paths.
> ...
Hi Stefan,
Thanks for the info (and sorry for my delay in responding). I'm working on
how to instruct our team around the issue now. If you have any advice to
handle this issue it would be really great to reference.
My current idea is that since there is the potential for extraneous tree
conflicts when merging back and forth between branches, it would be useful
for team members to do an initial merge, then do a second test merge in the
reverse direction to detect any tree conflicts which could affect future merges
and resolve them immediately. I think this will make the merging process
easier since there won't be leftover issues from previous merges to worry
about for future merges.
Then, if tree conflicts are found, do the second full merge (not test merge),
carefully resolve the tree conflicts, and then commit the parent directory
containing the resolved conflicts to the server. I think only directory names
and not files can be committed in this step to help keep the svn:mergeinfo as
clean as possible for things like Revision Graphing, etc.
Best,
Shaun
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416741
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-11 21:45:17 CET