Re: [Monotone-devel] patch serieses

[Daniel Carosone]

On Wed, Nov 08, 2006 at 08:14:16PM -0800, Nathaniel Smith wrote:
> > bug A fix --> update upstream v1 --> update upstream v2
> > bug B fix --> update upstream v1 --> update upstream v2
> > bug C fix --> update upstream v1 --> update upstream v2
[..]
> > Maybe monotone with its light weight branches could provide a
> > solution...
> 
> One approach might indeed be to have an "upstream" branch that you
> make imports into, a bunch of feature branches off of it (one for each
> current patch), and then a "release" branch which you get by merging
> together all the feature branches.

That is the approach I use (though I use the term "integration"
branch, rather than "release" branch).  The main reason is that
otherwise there's no sensible way to put a restriction on "propagate"
when you want to put back just some of the changes you've been
developing (or when one set is accepted upstream and appears in the
next release import).

The nice thing about this is that integration branches are where you
find out that there are conflicts between the feature branches, and
where you might resolve ordering and other dependencies as well.  The
corollary is that you try to *not* see these in the per-feature
braches.

What then happens is a matter of preference and discipline - the
objective being mostly to avoid doing work in integration branches
other than pure conflict resolution.  Often that means making a change
in a development branch to produce a result in the integration branch,
which can be a little confusing at the time but is much much clearer
when looking back later.

I was a little confused looking at njs's A, B, C diagram, especially
when it came to the reordering.  I didn't like that A polluted B, etc,
especially when that had to be undone.  My personal preference would
be to develop A, B, C independently, and establish the ordering and
dependencies between them via propagates to integration branches:

  prop A IA
  prop IA IAB
  prop B IAB
  prop IAB IABC
  prop C IABC

then if you need to abandon IABC and make an IACB instead, it's easy.

Beyond needing to do some initial approves (or explicit_merges) before
all these branches actually exist, you can then make development
changes to A, B, C pretty much independently, and reintegrate
(refresh) the IABC branches when you like.  You need to figure out for
yourself (eg, with -viz) when IABC is stale because IAB has been
changed.

You can do "sync from head" propagates from mainline to these branches
anytime, too; it's another matter of taste and circumstance as to
whether you do that for all the branches, or just the integration
branches. It can be more work, but I tend to think it's cleaner to do
this separately for each branch, rather than cascade a such propagate
along from IA to IAB to IAC along with other changes; I suspect it
helps if you need to reorder them later.

If you're developing the features for use against multiple releases
(rather than mainline) then you'll have a set of integration branches
for each release branch. This is where you won't want to propagate
into the "pure" A, B, C branches at all, but leave those based off the
older ancestors and integrate forward.  Projects like this often don't
really even have much of a mainline, they tend to start an integration
branch for the next release from the FCS of the previous.

You then publish your "rolling patch set" as the output of "diff -r
h:IA -r h:IAB" and so on - noting that h:IA is an immediate ancestor
of h:IAB after the propagate patterns above. You can also produce
other forms of the diffs for other perspectives.

All that said, though, the use model for externally maintaining such
patch files that I'm familiar with is in packaging systems like
pkgsrc, gentoo, and I assume debian and others: the point here being
that the actual sources being patched aren't even in the VCS at all -
at least not the VCS for the pkgsrc/portage/etc tree itself.  There's
just a distfile link and checksum to which the patches then get
applied.  All the above, including vendor branch imports, is a lot of
work just to maintain tweaks to someone's stupid configure script or
whatever - a simple 3-way-merge from the old and new distfile contents
and the old patched form is often enough when the pkg needs to be
updated.

The other use model (linux kernel) seems to me to be mostly an
artifact of historical practice driven by deficiencies and mismatches
in different VCS sytems, rather than an explicit preference to
maintain things as patches in their primary form.  For review and
approval they can be generated as above.

--
Dan.

pgpxAhLqqrUM6.pgp
Description: PGP signature