Re: [Monotone-devel] Mark merge for existence

[William Uther]

On 16/11/2007, at 12:17 AM, Markus Schiltknecht wrote:

> Hi,
>
> William Uther wrote:
> > > (which does not track merges). And try to get merging right for it.
> > Um, if it does not track merges, how do you "get merging right"?
>
> Sorry, I was unclear here. There are two different cases: one is the  
> sync vs async copy. The other problem you are trying to solve as  
> well is keeping track of deleted and undeleted files, and merging  
> that correctly.
>
> Under async copy, I understand copying of a file, where the copy  
> remains at the copied state and is independent of the origin from  
> that point on. That's what I meant with 'not tracking merges'.  A  
> sync copy, which would track merges would get all the changes to the  
> origin merged in as well, including getting deleted when the origin  
> gets deleted. Thus, a sync copy would certainly not help the die die  
> die merge problem.

Okie.  Async copy I have no issue with.  I think sync copy is hard to  
implement without something like OT merge.  That could be good, but is  
really hard to get right. ( See http://wiki.darcs.net/index.html/ConflictsFAQ 
 )

> But for undelete, or async copy, we'd need to be able to merge  
> revisions which resurrected the same file at different revisions,  
> for example. With async copy, I'm imaging that an undelete would  
> look like that:

I'm going to adjust your diagram a little, adding some new nodes

> REVISINO(node id -> filename)
> "changelog":
>
>                 A (1 -> fileA)
>                 "initial import"
>                  /            \   \-----------------------
>                 /              \                          \
>          B (1 -> fileA,      D(1 -> fileA,                 W(1 ->  
> fileA, Edited contents)
>             2 -> fileB)        3 -> fileA.resurrected)     |
>          "adding fileB"      "copy of fileA for undelete"  |
>               |                     |                      |
>               |                     |                      |
>          C (2 -> fileB)             |                      |
>          "deleted fileA"            |                      |
>                    \               /                       |
>                     \             /                       /
>                      \           /                       /
>                     E (2 -> fileB,                      /
>                        3 -> fileA.resurrected)        /
>                     "clean merge"                    |
>                           |                          |
>                           |                          |
>                      F (2 -> fileB,                  |
>                         3 -> fileA)                  |
>                      "rename to original filename"   |
>                           \                         /
>                            \                       /
>                          What happens here? - revision X
>
> In this example, fileA got deleted in revision C. To resurrect the  
> file from revision A, monotone would have to add three revisions,  
> which might be a disadvantage. OTOH, revisions aren't expensive.

Are you expecting that revision X includes the content changes made in  
revision W or not?

If you're not, then I'm not sure it makes a great un-delete.  It is an  
ok work-around, but not perfect.
If you are expecting that those changes get merged in, then you have  
to keep track of which sets of node IDs are equal, and you have to  
decide whether the original delete gets merged in.  What about another  
delete in yet another branch?

> > I have no objections to that at all. (And you could add that as  
> > well as what I'm suggesting.)
> > However, if you try to modify it to get merging working then I  
> > think you travel down the path to Operational Transformation (OT)  
> > style merging (See also DARCS).  This could work well, and I think  
> > would make for interesting text merge capabilities too, but is a  
> > huge amount of work to add it and get it right.
>
> Uh.. I'll have to read on that, thanks for the pointer. However, I  
> don't (yet) see why I'd need another merge algorithm at all.

Well, if you started to want to get file contents merging to work with  
the different sets of node ids, it might help.  There are probably  
other options too.  OT should be able to handle both sync and async  
copy and the associated merging.  It has its issues with conflicts.   
I'm not seriously suggesting that you put that into monotone, which is  
why I'm concerned about this approach.

> Hm.. to me that sounds like circumventing rosters, which doesn't  
> sound too good. But hey, you are saying it's efficient, so please go  
> ahead!

It is... making rosters dynamic when there are deleted nodes.  All of  
that same machinery is used, just not stored in the DB.

Cheers,

Will       :-}