Markus Schiltknecht wrote: > Thomas Moschny wrote: > >> A B > >> / \ /| > >> | X | > >> | / \| > >> | C D > >> |/ > >> E > >> > >> Suppose A has "add foo", B has "add foo", D is a simple merge, so > >> D contains a single sutured file name "foo". Suppose also that C > >> has "rename foo bar", and E is a simple merge, so E has two files > >> "foo" and "bar". > >> Now, I merge E and D. What happens? > > > > If D actually dropped both 'foo' nodes and created a new one 'foo' node > > with merged content, merging D and E would be a clean merge: drop 'foo' > > from A and drop 'bar' (being 'foo' from B), and add the new 'foo'. No > > conflict (with or without DieDieDie, in that example). > > Hm.. no, we cannot let drop merge cleanly with suturing.
Agreed, but in the example, this is not the case anyway. The only thing I said was: *If* we implemented suturing as drop,drop,add (all within D), and not cared about the relationships between the newly created file and its predecessors, then there were no conflicts at all while merging D and E. *But*, I changed my mind, and now think that we must care about file identity relationships. What we really want, is this: Pretend we could go back and give both 'foo' nodes in A and B the very same node identity. The whole monotone merging machinery would work as expected. However, we simply can't do that. We can't go back and treat two different file identities as a single one. Well, we can do it, locally, but only *as soon as we know about the users wish to do so*. And the user in turn cares to tell us only when ncc conflicts arise. And that's the point with Nathaniel's example: D knows about the problem, but E does not, so in E we have two nodes, and a delayed (=not yet resolved) content conflict popping up when we merge D and E. > > In *that* case, > > there would be aliveness conflicts (and probably also a chain of content > > conflicts following) for old 'foo' and 'foo' aka 'bar' nodes, like > > Nathaniel described. > > Uh.. why does marking aliveness state influence the amount of content > conflicts? > > > But that probably shouldn't scare us anymore after we have learned > > how to control resurrection and the content conflict chains arising > > there. > > I've completely lost you here, sorry. Let me put it in other words: Killing DieDieDie and implementing suturing properly will both yield merges where we are confronted with a series with more than two content conflicts on the same file. > Yeah, I'm aware of that problem. However, I don't think suturing (nor > copying) has much to do with file resurrection. They do, see above. > > That's why I am still thinking we need a new storage scheme that allows > > easily access to relevant parts of a roster - as we already do for > > restricted log and annotate, but in a cleaner fashion. > > Hm.. you mean splitting the aliveness information from rosters, as we > have split height information? Or what do you have in mind? No, no. Height information is also a cache, but at the level of revisions, and totally unrelated here. Rosters are caches carrying per-revision, per-node information (see my other post), but are currently accessible per-revision only. All I'm saying is that we should break this up and allow access to node-specific parts of a roster. Regards, Thomas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
