How to cope with patches sanely

[Manoj Srivastava]

On Thu, 21 Feb 2008 16:23:10 +0100, martin f krafft <madduck at debian.org> said: 

> also sprach James Vega <jamessan at debian.org> [2008.02.21.0020 +0100]:
>> The difference here being that feature branches are, in my
>> experience, changes against the pristine upstream source.  The
>> merging of different feature branches is done in some integration
>> branch.  Quilt patches are a dependent series where the merging of
>> changes is inherent in the patch ordering.  Thus it's easier to get
>> an "upstream ready" patch from $vcs than from a series of
>> interdependent patches.

> ... unless feature branches interdepend and you have to store
> dependency information somewhere.

        I am not sure you have understood feature branches.  They are
 independent, no matter what the overlap. Each feature branch tracks one
 feature against upstream, no matter how the other features work.

        The overlap management is done in the integration branch. This
 is significantly different from a quilt series, as others have already
 mentioned in this thread,which is a dependent series of
 linearized patches; and a change in an earlier feature impacts all
 subsequent patches (and  quilt is good at automating the handling of
 that impact). [[duplicated so this can be archived on the vcs-package
 mailing list as well]]

> "Congratulations, you have just reinvented $patch_manager".

        Or the patch manager does integration. *Shrug*.  Someone has to
 do integration sometime.  That is the nature of the beast.  The trick is
 to do it once, and never have to think about it again.

        What are the most common cases? 
 A) There is a new upstream delta. In this case, 
    1) either there is no conflict in any feature branch, in which case
       the upstream delta applies to each feature branch and integration
       branch with no manual thought required.  Indeed, I have a script
       that does this case for me with one command line invocation:
       arch_upgrade.
    2) The upstream change conflicts with a feature. A human can then
       disambiguate that feature branch, and the same change then is
       applied to the integration branch.  Only once did I need to think
       about it.  
    3) If more than one feature was affected, then I'll need to
       intervene once for each feature affected, and possibly once more
       for the integration branch.  Again, I think this is the minimal
       disambiguation that is needed.
 B) Development happens on the feature branch.
    1) There is no conflict with any other feature.  The delta on the
       feature branch is then applied mindlessly to the integration
       branch.
    2) Development on one of the branches conflicts with one or more
       other features. Here, the human has to figure out the difference
       on the integration branch -- once.

        So, in my experience, A1 is the most common case, followed by B1,
 A2, B2, and A3. The only time I have to even thing about doing
 something manual is A2, A3 and B2 -- and in those cases, human
 intervention can not be eliminated, no matter what tools you use.

        My point is that I never have to even think about different
 features or patch  series except in cases where human intervention is
 indispensable anyway. I like that. I am lazy.

        manoj
-- 
Reliable source, n.: The guy you just met.
Manoj Srivastava <srivasta at debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C