Re: Thoughts on merge tracking

On 3/7/07, Peter Lundblad <plundblad@google.com> wrote:
>
> Mark Phippard writes:
> > In the above scenario, when each pass of the merge runs it is possible
> that
> > one or more conflicts are created from the merge. If any conflicts are
> > created, then merge can finish the current pass it is performing, but it
> > cannot continue on to do the next pass unless those conflicts are
> resolved.
> >
> I see No reason why the whole merge process needs to stop just because
> a subtree (possibly just a file) has conflicts. We just need to exclude
> that part of the tree and notify the user.

I was involved in a long conversation on this topic with Dan, Paul Burba and
Jack Repenning while I was at CollabNet last week. Daniel made a very
convincing argument to me that it needs to be this way. Just think of the
simple case where you have two files foo and bar. Suppose that when we do a
large merge involving several "passes",there are conflicts in foo, but not
bar. So foo only has the initial revision range merged, and bar has all of
them. In some cases, this will be fine. But if foo relies heavily on bar,
it might become extremely difficult to resolve the conflicts in foo since it
is effectively at a much older revision than bar. foo could reference
functions in bar whose signatures have changed, or no longer exist. Even
worse is that the user could theoretically resolve the conflicts and commit
them to the branch without merging the rest of the changes for foo. If the
merge process stops after the revision range that produced the conflicts in
foo, then at least foo and bar are both at the same revision and the
conflict resolution process should be easier to manage.

So for this reason, ignoring the additional technical difficulties that
would arise from trying to merge other parts of the tree, I agree with Dan
that the merge should stop after any pass where it gets conflicts.

> I see my "merge and go for a coffee" argument reappearing;)
> (See an earlier thread discussing interactivity.)

That is definitely a worthy goal. I think that interactivity would be bad
for any large trees where the merge time is going to be long.

I think it should be possible to push the questions towards the end
> of the process by excluding problematic subtrees and continuing merging
> as sketched above. I'll try to write up my idea of the augmented merge
> algorithm in a sparate thread. But you're right about the general
> problem.
> That's why I'm opposed to interactive merge conflict resolution in the
> cmdline client by default. I think we need to support the user bailing
> out
> to resolve conflicts and restart the merge to continue where it was *and*
> have conflict callbacks to support conflict resolution in the process.

I think you won that argument. I think the command line will bail out. I
guess my point was that I do not think either solution is going to work real
well in some of the more difficult scenarios. That is why I suggested the
only real long term solution would be to remove the problem by somehow
making the merge be able to do everything in one pass. That being said, I
am sure it would be of tremendous help to Dan and the others working on
merge tracking if the community would get more involved in putting their
thoughts on paper. There has not been very much feedback (that I have seen)
provided to Dan from the other developers.

> > Finally, in either solution, an inconvenience exists that a user could
> be
> > resolving conflicts in areas of code that are going to be removed in
> later
> > stages of the merge.
>
> Yes, this is a problem that has bugged me for a while.
> Maybe this is solvable if there is a way to avoid getting the information
> for paths that are going to be deleted. I don't know if svn diff
> --summarize
> could be used here. Also, the sparse-directories branch has the notion of
> depth that could be useful.

Yeah, I wasn't even talking about the case where the whole file is deleted,
which is obviously even worse. I was just thinking of resolving conflicts
in functions or blocks of code that are going to be deleted in subsequent
revisions.

> What I'm trying to say is that our current approach doesn't have
> to be as bad as you suggest, but it is still not as good as we'd want it.
> I'll try to summarize the 1.5 merge algorithm in another mail.

In thinking about it more I agree. The most common merge use cases should
work fine with what we are doing. The problem is that there are some known
use cases that are not all that uncommon where it is not going to work real
well. I have been focusing on the extreme worst cases, but partly because I
know those scenarios are not at all uncommon. Even if they are not the
norm, they do occur and they are probably also the users that want the
feature the most since they probably are the ones having the hardest time
working with the current merge.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/