Hi,
Thomas Moschny wrote:
There can, that's what suturing is about.
Not if suturing conflicts with renaming and dropping, which prevents
such a merge with certainty. That's the point of my proposal and why I'm
thinking it's simpler (to implement as well as for the end user).
Because it avoids even fancier merges.
Or are you stating that suturing shouldn't conflict with renaming or
dropping?
It is the same thing happening in C,
where we are suturing 1 and 2 both wanting 'foo' into 1&2. Why shouldn't that
be possible again in F for 1 and 1&2 ?
Because E and C represent conflicting user wishes on how to solve the
original ncc between A and B.
E C
| G: - # rev G drops 3 (i.e. the sutured 1&2) here
H: 4,foo,v /
\ 5,bar,y / # rev H saves nodes 1 and 2 by
\ / # copying
\ /
F: 4,foo,v # a clean merge now. 1 and 2 are gone due
5,bar,y # to the suturing into 3, which got then got
# dropped in G.
You are cheating here. We don't have well defined nor understood semantics for
copy yet.
Well, I'm proposing some semantics, and I'm just now trying to
understand 'em ;-)
And by simply exchanging 3 for 1&2, or 4 for 1 and 5 for 2, you are
pretty much hiding what we are (well, I am, at least) talking about:
Establishing connections between different node identities.
I've stated at the beginning of my previous mail, when explaining the
1&2 -> 3 merger: "Of course the extra information 'created from suturing
1 and 2' still has to be maintained".
However, that has nothing to do with content merging, because we try to
keep content merging separate from aliveness merging.
That is, a new node needs to able record the fact somewhere that it wants to
inherit (or asymmetrically share) identity from (with) another node.
Sure. That information would need to be part of the changesets, for one,
AFAICT.
What I'm thinking of (implementation wise) is extending the birth record to be
able to contain a list of 'ancestor' nodes, in terms of node paths in the
respective parent revision. Note (a) that we don't have node_ids there, so
nodes must be referenced by name, and (b) that we certainly don't want to
allow nodes to be referenced in other revisions than in its direct parents.
Otherwise we would create a new graph that can not be embedded in our
revision graph, and my intuition says that would be a very bad thing (tm).
This would allow suturing and asymmetric copying, but not resurrection in the
copy-sense, "hopping" over a whole part of the history. But that's fine
anyway, because you can always commit a child revision of an old revision
where the file in question was still alive and merge that with your current
head, and that's the Monotone way of doing it.
Uh.. okay, I'm not quite grokking that approach now. Let me think about
it for a while, ja?
Regards
Markus
_______________________________________________
Monotone-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/monotone-devel
