On Thu, 21 Feb 2008 16:23:10 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach James Vega <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
