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

[Pavel Cahyna]

On Fri, Dec 26, 2008 at 04:28:53PM -0500, Stephen Leake wrote:
> Pavel Cahyna <address@hidden> writes:
> >> 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. 

Sure, I said "cherrypick a selected change", implying that I don't want
the others.

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

This is not feasible as a general solution, because it would require
knowing in advance all the conceivable future uses of the branching scheme
at the time one commits a revision. I.e. it would require knowing in
advance what changes will anybody ever want to merge separately from the
others.

Consider sources with a main (developement) branch and release branch(es).
You don't want to merge the whole main branch to a release branch, ever.
One just carefully selects bugfixes and minor new features from the main
branch and applies them to a release branch. pluck would be the way to do
it if it DTRT. I do not see how better one could design this branching
scheme...

BTW - does monotone itself have release branches? I.e. are bugfixes
merged to a stable branch instead of requiring everybody to update to the
fixed version of the development branch?

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

Maybe it intelligently handles the case when a file common between the two
branches is renamed in one of them before the pluck?

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

I think that making it work like "cvs up -j" does would be an improvement,
even if it proper rename tracking were lost in exchange.

Pavel