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

[Stephen Leake]

Pavel Cahyna <address@hidden> writes:

>> 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.
>
> Can it? I thought that files added by "pluck" are as if added
> independently. 

That's apparently how it works now, but I think it should be smarter.

> Are you sure they have the same node id in the database?

Before 'pluck' is executed, there is only one 'f' file; it is given a
new node id when created, and maintains that node id when modified.

However, 'pluck' apparently gives it a new node id, twice.

I think 'pluck' should simply add the original node id to the current
revision.

Maybe that model would break other things; it depends on why you are
using pluck.

There is this comment in the implementation of pluck in
cmd_merging.cc:

  // To perform the merge, we use the real from roster, and the real working
  // roster, but synthesize a temporary 'to' roster.  This ensures that the
  // 'from', 'working' and 'base' rosters all use the same nid namespace,
  // while any additions that happened between 'from' and 'to' should be
  // considered as new nodes, even if the file that was added is in fact in
  // 'working' already -- so 'to' needs its own namespace.  (Among other
  // things, it is impossible with our merge formalism to have the above
  // graph with a node that exists in 'to' and 'working', but not 'from'.)

This states that the current behavior (adding new nodes for 'f') is
deliberate, but I don't think it justifies it.

>> 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?
>
> Well, if you cherrypick a selected change from one branch to another and
> this change creates new file(s), it is likely that later you will need
> other changes/fixes to them so you will pluck again a changeset which
> patches those newly created file(s).

This is normally handled by branches, and merging the _whole_ branch.
You are implying that there are other changes in the source branch
that you _don't_ want. 

So the general solution is to design your branches better, so pluck is
not necessary.

If you don't have sufficient control over the branching policies, I
can see how pluck might be part of a useful workflow.

> There are already two tests for the directory variant of the bug: 
> pluck_directory_bug_1 and pluck_directory_bug_2. The first has a commit
> between the plucks so is closer to a realistic situation, while the second
> does not have any commits between just like the one I showed here.

The current pluck implementation builds three rosters, does
a merge, computes a changeset from the 'from' revision to the merged,
and applies that changeset to the working tree.

I don't understand why it doesn't just apply the 'from to to'
changeset to the current working directory, as the description of the
command implies. The description goes on to say using a merge allows
pluck to "intelligently handles renames, conflicts and so on"; this
case demonstrates otherwise :).

It would be interesting to test the none-merge approach and see if it
solves this current problem and those tests.

Interestingly, the existing test "pluck_basics" demonstrates the same
conflict, but implies it is the correct/desired behavior.

I suspect there isn't a way to make 'pluck' do what everyone wants of
it.

-- 
-- Stephe