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

[Stephen Leake]

Pavel Cahyna <address@hidden> writes:

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

You can always start over, you don't have to get it correct from the
beginning.

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

It's better to implement fixes that belong on the release branch on
the release branch, and then merge the release branch to main. That
way you don't need pluck. You do need to decide what fixes belong on
the release branch, and what belongs on main instead.

> BTW - does monotone itself have release branches? 

No, just release tags on the main branch.

> I.e. are bugfixes merged to a stable branch instead of requiring
> everybody to update to the fixed version of the development branch?

Simple bug fixes are done directly on main. New features that need
reviewing and/or experimenting should be done on separate branches.

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

One of the tests demonstrates that, yes.

-- 
-- Stephe