[darcs-users] Darcs in kernel-like development model

[John Goerzen]

Hi folks,

I'd like to get some feedback from all of you on best practices for
Darcs in what a lot of people call the kernel development model (used
for the Linux kernel).

In this model, there is an upstream that many people feed patches to.
Upstream wants only clean patches; that is, the final, good, working
implementation of a feature and not all your history of development on
it.

Various developers maintain local branches of the project.  Each
developer may be working on multiple features, which may or may not
depend on the other features.  Each logical feature may touch many
files but should be a single logical, complete patch when sent
upstream.  Upstream meanwhile is also updating and patches need to be
kept current to apply cleanly to upstream.

People use various tools to do this.  Patch queue management tools
like quilt or Mercurial's mq are common.  Others use git with frequent
use of its rebase feature, or Mercurial with transplant.

So if we model this workflow on a DVCS like Mercurial or Git, here's
what we wind up with.  Traditionally, when you have a local branch of
some upstream project, you'll have a history of commits, with
merge/conflict resolution changesets around whenever you merge from
upstream.  You have a complete history, but not a final, complete
patch of each logical feature.

That model doesn't work here.  So what people do is use git rebase or
hg transplant.  When a new upstream version comes out, you use
rebase/transplant to extract all your local patches against the
previous upstream and re-apply them against the new upstream.  If
there are conflicts, you stop to fix them for the individual patch,
then resume.  Later you presumably throw away your former local
development branch.

Now, this model works well for private repos.  In both git and hg, it
is difficult to use -- though not impossible -- if you are sharing
repos with others.  That seems similar to using amend-record in darcs.

Now, how would we accomplish this in Darcs?  As far as I know, Darcs
has no equivolent of rebase.  While it does have amend-record and
similar unrecord types of features, it does not have a way to
arbitrarily merge two patches back in the history -- at least not a
convenient way.  And as far as I can see, there's no equivolent of
rebase.

So what are your thoughts on the best way to do this?  And, is there
some nice feature of Darcs that lets us avoid some of the pitfalls of
the approach that uses git rebase or hg transplant, such as:

 * Loss of development history due to having to throw out old branches

 * Inconvenience of sharing repos with others (note that
   any use of darcs amend-record, unrecord, etc. will fail on this,
   though won't necessarily be worse than git/hg)

Thanks,

-- John