Mark Phippard writes:
> 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
Say we are mergin revisions 1-8. foo already has revision 4, but not bar.
The current merge alrogithm would do the following merges:
1) /foo, 1-3
2) /foo, 5-8
3) /, 1-8
So what happens if 1) results in a conflict?
We could stop immediately, leavning / *and therefore bar) without revisions
1-4. foor@2 might have introduced a dependency an bar@2 which
makes it harder for conflict resolution.
We could continue merging /, but only to revision 4. This would avoid
dependencies *in this case*, but not in general, because if some other part of
the subtree was merged before foo, then it might include newer revisions that
might introduce dependencies. This could also cause lots of conflicts in
the rest of the subtree (in a more interesting case than two files, obviously),
that wouldn't have occured if / except /foo was merged all the way to
revision 8.
So, I think the assumption that we can leave the tree in a consistent
state after a conflict is misguided. I also think we have to accept the fact
that if you get conflicts in a complicated merge, you might not be able to
compile/test the resolution before continuing the merge.
> 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
They could theoretically screw up in many ways...
> 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.
>
I think you're oversimplifying. If we have cherry-picking in subtrees,
there is not a single non-overlapping range of revisions to merge for
the whole subtree.
> 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.
How do you define a pass?
> 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
I agree completely. The question is if we need to come up with the perfect
solution in the first release with merge tracking.
> 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
It would. I'm not disagreeing here. I don't know how that would work, though.
OTOH, there is nothing as I see it that hinders improving the merge
algorithm in future releases.
> 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.
Agreed. If we want this to happen quicker, we need more people to work on it.
I'll try to offer what I can in my limited time;)
>
>
> > > 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.
Yeah, that's a good point and this is an annoyance. I don't know how easy
it would be to compose a series of diffs into a single one.
We also have
http://subversion.tigris.org/variance-adjusted-patching.html
So, there's clearly room for further research here. The questions is,
would merge tracking be useful without these things, so we could get a working
foundation out in one release which gets improved later on.
>
>
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 8 11:02:13 2007