Dan, thanks for thinking about this.
On Wed, 12 Jul 2006, Daniel Berlin wrote:
> So i'm not sure your current idea of stopping as soon as a single
> conflict happens during a merge-range application is a good idea:
>
> 1. It's not what we do now in the same situation (effectively all of our
> non-single rev merges are merge-range applications, the range is contiguous)
To me, this change in behavior seemed like one of the biggest
problems with this strategy.
> 2. Finishing a large merge would take a very large number of calls to
> svn merge if you have a lot of conflicts, because you are stopping the
> merge each time, even if the conflicts are not in the same files.
> 3. You end up with more work, particularly in the case where the same
> lines get changed *again* in a later revision (now you get two conflicts
> instead of 1).
>
>
> I expect merge to do what i tell it to, and to let me deal with the
> problems that happened as a result. I don't know of *any* VCS tool that
> will stop merge application at a conflict because it thinks it is
> "better for me" in some way :).
I believe that some VC tools throw you into a "conflict resolution
mode" when attempting a merge that conflicts (similar to our merge
conflict markers, but often visual). However, I assume you enter this
mode after *all* necessary revision ranges have been applied to your
WC -- diverging from this model does seem like a major downside.
I too would prefer to be consistent with other tools by applying all
necessary revision ranges in a single (end-user) 'merge' operation.
> At a bare minimum, I would think the user experience would be severely
> affected by a change to stop merge application, unless you would only
> stop merge application if we have a conflict on the same lines of the
> same file between multiple merge ranges.
We'd discussed this possibility, but given our current architecture,
I'm assuming it would be much more difficult to detect.
> Even then, i'm still not so hot on the idea, but AFAIK we don't have a
> good way to replace merge markers with a newer set of merge markers to
> handle these cases. :)
This "multiple conflicts" problem was what prompted prosal of this
scheme in the first place. Let me re-state the problem:
Apply all necessary revision ranges for a merge, while avoiding
repeated merges and handling multiple, overlapping conflicts in a
meaningful way.
So while we have avoidance of repeated merges coming along nicely,
handling for overlapping conflicts is non-existent. Currently, we
produce nested conflict markers (UGHH!). The ability to somehow merge
conflict markers does seem like the preferred way to deal with this
problem (and is consistent with other VC tools).
ATM, I have no ideas on how to pull that off. There's no way to
pre-calculate merge conflicts, given that the WC may contain local
changes. Anyone have any thoughts on a strategy for implementing this
(e.g. some sort of callback inserted into the textual merging code)?
If not, is this something we can punt until later? (I tend to think
so, given that I suspect this is something of an edge case in
practice, and a subsequent change in behavior won't be very noticable,
and will fix what's an annoyance for any users that have encountered
the previous behavior.)
- application/pgp-signature attachment: stored
Received on Wed Jul 12 19:34:08 2006