Counterintuitive tag behaviour (broken design?)

[Georg-W. Koltermann]

Am Dienstag, den 13.03.2007, 11:54 -0500 schrieb Matt Mackall:
> Head A                  Head B              
> 01234567  foo -> 0      01234567 foo -> 0
> deadcafe  foo -> 1      deadcafe foo -> 1
>                         01234567 foo -> 2
> 

What about this:

Head A			Head B
0123 foo -> 0		0123 foo -> 0
4567 foo -> 1		cdef foo -> 1
89ab foo -> 2		ff00 foo -> 2
cdef foo -> 3

Would the final tag value be cdef or ff00?

Based on ranking it would be cdef.  But my guts feeling is that it
should be ff00.

My feeling is based on the assumption that the user who placed the ff00
tag value already had seen the cdef one in his view of history, and
deliberately replaced it by ff00.

Actually we cannot be really certain that he replaced cdef when he
assigned ff00.  It might be that he was seeing another "active" value at
that point in time, from another head.  But that could only have been
possible if a) that other branch had already superseded the cdef value
even then, or b) some kind of tie-breaking had made another value than
cdef preferable to cdef.  So however we look at it, if ff00 comes after
cdef in some head, then at the point in time when ff00 was created it
was prefered to cdef.  That should be reflected in picking the overall
tag value.

(Math once was a favourite of mine at school, but now can't imagine how
to put this more formal, more towards being mathematically provable.  It
remains my "feeling" only.)

Now, what really worries me is how could merges garble up that sequence.

E.g., if we have:

Head A			Head B
0123 foo -> 0		0123 foo -> 0
4567 foo -> 1		cdef foo -> 1
89ab foo -> 2		ff00 foo -> 2

we get a merge conflict.  The user could resolve it by selecting lines
two and three from head A or from head B, or combine both contributors
in either order.  In reality, when there are various tags intermixed,
not just the one foo tag, it will be really unintuitive the the user, it
will not be apparent what the right resolution should be.  

When I merged tags in the past I usually combined both contributors, and
I didn't worry about order (I picked either order depending on my mood
of the day... I believe I didn't yet meet real conflicts of values for
the same tag, I rather saw textually conflicting lines in the file,
where the lines were about different tags.)

So I'd like to say I'm not convinced that the algorithm I implemented in
my patch is the best and final version that can be found, but it's a
definitive improvement over the old behavior, and it doesn't require a
data format change.  It's good enough for my needs.  I update tag values
often, using tags somewhat like a branch name, to indicate the latest
"blessed" version for a particular task.

--
Regards,
Georg.