On 7/12/06, Daniel Berlin <dberlin@dberlin.org> wrote:
> Uh, so, imagine their had been no two merges, but you had merged the
> already-merged revision.
>
> The conflicts in this merge may have come from any single revision
> change, but the end result will still represent them all.
>
> Why do you think we should do something different just because we've
> elided a revision in the middle?
Well, mainly beacuse we don't currently handle merging into a
conflicted file sanely. As dlr already mentioned, overlapping
conflict markers don't work, etc. If you want to make that work then
fine, but honestly I still think the idea of merging into an already
conflicted file is kind of strange.
> >
> > Say I'm merging r10:20 into my working copy, and I've already merged
> > r15. That means there are two ranges to merge. When the first range
> > results in a conflict for a given file that is also modified in the
> > second range, what should it do?
> > You can't very well try and merge
> > into the conflicted file, can you?
>
> Why not?
Ok, let me restate. We currently don't handle such a case very well,
and I imagine that the presence of conflict markers in the file will
make our diff3 implementation have a fair amount of trouble actually
applying the change.
Other than that though, it still just feels odd to attempt to pile
more diffs onto a file we've already figured out that we can't merge
successfully. It seems more likely that problems with the second half
of the merge would be avoided if the initial conflict was resolved
first.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 12 21:04:38 2006