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

[Markus Schiltknecht]

Hi,

Thomas Moschny wrote:
> > [...]
> > but:
> >
> >   0     file a exists
> >  / \
> > 1   3   file a is changed (differently in both 1 and 3)
> >
> > 2   4   file a is deleted (both in 2 and 4)
> >  \ /
> >   5
> >
> >   6     file a is resurrected
> >
> > Which version should mtn resurrect? (it could ask the user, but we
> > don't do that for other non-content issues, so what would be the
> > default?)
>
> This is the well-known problem of delayed content-conflicts arising on file 
> resurrection. It *is* a content-conflict, and must be propagated to the user. 
> In your example, there are only two changes conflicting, but you can easily 
> imagine a case with N conflicts having suddenly to be solved.

Does the user really want to resurrect a file just by its node id?

You might even have renames, so that the file to be resurrected isn't 
currently visible. How's the user supposed to resurrect the file then?

Doesn't the user rather want to resurrect a file from a specific 
revision (possibly with a new target filename). That would make 
resurrection a simple copy, and we wouldn't need to carry on node ids 
forever.

In the above case, the user would then have to decide if he wants to 
resurrect file a from revision 1 or 3. If he really wants to keep *both* 
edits, he would have to resurrect both and then suture them...

Regards

Markus