Re: [Monotone-devel] sutures [Re: Time for a release]

[Stephen Leake]

Pavel Cahyna <address@hidden> writes:

>> > I am asking mainly because they could fix a really annoying problem
>> > with "pluck" IIUC: that if you pluck a revision which introduces a
>> > file, monotone does not recognize it as the same file as the
>> > original one and subsequent pluck which modify this file will fail.
>> > See
>> > http://lists.gnu.org/archive/html/monotone-devel/2007-08/msg00159.html
>> 
>> I don't see how "file suture" would solve that; there are not two
>> files being sutured. 
>
> OK, suturing applies only to files, not directories?

In the current implementation, yes, but there's no signficant reason
for not suturing directories; I just wasn't working on it.

I still don't see how suturing helps here. Perhaps you could repeat
the example, and add fictional suturing commands that would solve it.

> Here is another test case for files instead of directories
> 
> MTN=${MTN:-`command -v mtn`}
> $MTN db init --db=test.db
> $MTN setup --db=test.db --branch plucktest2.branch plucktest
> cd plucktest
> $MTN add .
> $MTN diff
> $MTN commit -m'empty first rev'
> BASE=$($MTN automate get_base_revision_id)
> touch f; $MTN add f
> $MTN commit -m'add a file'
> FIRST=$($MTN automate get_base_revision_id)
> echo "change" > f
> $MTN commit -m'change the file'

At this point, your workspace has this directory tree:

    dir plucktest
        file f (containing "change")

> SECOND=$($MTN automate get_base_revision_id)
> $MTN up -r$BASE
> $MTN mkdir b
> $MTN commit -m'some other random nonconflicting change'

now you have:

    dir plucktest
        dir b

> $MTN pluck -r$FIRST

now you have:

    dir plucktest
        dir b
        file f (empty)

> $MTN pluck -r$SECOND

on mtn head, this gives:
mtn: [left]  02a688ce9bafe8c0bac5712d1754265808ba2f1e
mtn: [right] 415e53d24affc7ac2bf84ee3330a211bf86756a2
mtn: warning: Content changes to the file 'f'
mtn: warning: will be ignored during this merge as the file has been
mtn: warning: removed on one side of the merge.  Affected revisions include:
mtn: warning: Revision: 415e53d24affc7ac2bf84ee3330a211bf86756a2
mtn: error: no changes were applied

This isn't right; the file is not removed on one side of the merge. So
this is simply a bug in the current monotone.

You show the error from the automate_show_conflict branch below.

> It seems to me that "f" created by the first "pluck" and the one patched
> by the second are really files to be sutured, because they are actually
> the same file but monotone does not know that.

That makes sense, since the user originally only created one file 'f'.

However, I don't think they should be sutured; mtn should recognize
them as the _same_ file; they have the same node id in the database.

> with the new file-based example:
>
> mtn: conflict: duplicate name 'f' for the directory ''
> mtn: added as a new file on the left
> mtn: added as a new file on the right
> mtn: conflict: file 'f' dropped on the left, changed on the right
> mtn: error: merge failed due to unresolved conflicts

These two conflict messages are conflicting; one says there are two
new 'f' files, the other says one was dropped. So mtn is confused.
(which is just an example of how much work there is to do on this
branch)

>
> How to use suturing in your branch? 

There is not (yet) a user command to suture. See the various
'tests/resolve_duplicate_name_conflict*' tests for the conflict
resolutions that are implemented; one of them probably handles this
case.

It appears that 'pluck' introduces a whole new set of conflicts that
need resolution. Although as I said above, I think 'pluck' should be
intelligent enough to know that the two 'f' files are in fact the same
file in this case.

On the other hand, 'pluck' is a somewhat dangerous command in the
first place. Can you give a high level description of why you are
using it? In particular, using it twice?

-- 
-- Stephe