monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] resolving name conflicts; file suturing vs drop


From: Thomas Moschny
Subject: Re: [Monotone-devel] resolving name conflicts; file suturing vs drop
Date: Wed, 7 May 2008 23:34:59 +0200
User-agent: KMail/1.9.9

Hi Markus,

Markus Schiltknecht wrote:
> Can you please be more specific? Which three versions of the same file
> are you referring to? I only see two [...]

Ok, here's the graph again. But be warned, we need a lot of characters ;)

   A: 1,foo,v   B: 2,foo,w
    /\          /\
   /  \        /  \
  |    \______/____\
  |          /     C: 1&2,foo,x
  |         /        \
  |        /          \
  |       D: 2,bar,y   \
  |______/              |
  E: 1,foo,v            |
   \ 2,bar,y            |
    \___________________|
                     F: ???

It looks more complicated, but it isn't. I just added sort of a manifest to 
each revision, with the following format: "REV: node_id,path,contents".

A and B create foo independently, with different contents. D renames the one 
from B to bar and changes its content. E is a simple merge, no magic. It 
contains both files, foo and bar with different contents. Now, in C suturing 
takes place, denoted by the node_id '1&2' (whatever that means). In C also a 
content merge took place.

Now, consider F, merging E and C. How does its manifest look like?

I think there are two possibilities: "F: 1&2,foo,z" or "F: 1&2,bar,z". In both 
cases, there are three contents to be merged: x, v, and y, and thus two 
content conflicts to be solved.

Another variant would be: "F: 1&2,foo,u; 2,bar,y", i.e. F containing two 
files. In *that* case there would indeed be only a single content conflict: 
merge x and v into u.

What do you think F should look like in that scenario?

Regards,
Thomas

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]