On Wed, Nov 11, 2009 at 12:43:06PM -0800, Shaun Pinney wrote:
> > > 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.
I'd like to take a step back first, and ask:
Why do you need to merge back and forth between two branches?
If you can simplify your process such that you only ever merge in one
direction for a given branch (either into the branch or out of the branch,
with the special exception of re-integration which causes a branch to die),
flow of change will be much easier to understand for developers and it
is much less likely that you'll run into merging issues in the first place.
I am not saying that your idea is wrong, just asking whether you've
considered if a simpler solution will do the job.
Could you draw a diagram showing one instance of each type of line of
history you need (e.g. release branch, main line, feature branch) and
different kinds of arrows indicating types of merges you need to do (e.g.
catch-up/rebase merge, cherry-pick merge, reintegrate merge)?
Then we could work with that and think it through.
Of course, the less lines and arrows you can get away with, the better :)
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2416766
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-11-11 22:31:26 CET