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

[Pavel Cahyna]

On Fri, Dec 26, 2008 at 09:43:17AM -0500, Stephen Leake wrote:
> 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.

I am not sure how would fictional suturing commands look like
in general, but basically I mean that the directory "a" added by the
first pluck should be sutured with the directory "a" added by the second
pluck because they are actually the same. The same with the file "f" in
the file-based example.

> (...)
> > 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.

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

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).

My example is a bit artificial bcause it shows two successive plucks. In
reality it would look more like:

pluck from branchA to branchB, creates file f
hack on branchB
later:
note that branchA has interesting fixes for the file f, pluck again ->
conflict

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.

Pavel