On Mon, 25 Feb 2008 10:34:55 +1100, Ben Finney <[EMAIL PROTECTED]> said:
> Manoj Srivastava <[EMAIL PROTECTED]> writes:
>> David Nusinow <[EMAIL PROTECTED]> said:
>>
>> > No matter what you want to say about your feature branches, you
>> > *must* apply them in a linear fashion to your final source tree
>> > that you ship in the package. This is no way around it.
>>
>> But there is no such linearization, not in the way that quilt et al
>> do it. The state of such integration is not maintained in the feature
>> branches; it is in the history of the integration branch.
> Is this (the integration branch and its history of changes) not the
> linear sequence of changes that David Nusinow is asking for?
No, it is not. I Apply a update to feature A. The comes an
upstream update. Then updates on feature B, a patch that needed
conflict resoution, then patches on branches C, D, and A again. Another
upstream change.
At this point, none of the original patches to A, B, and C apply
any more -- and then come another upstream update, and all the patches
get even more bent out of shape.
>> And the integration branch does not keep track of what changes come
>> from which branch -- that is not its job.
> Doesn't each commit message in the integration branch's history state
> what merge you were performing at each revision?
It usually states what changes were made, not necessarily what
feature branch I imported from.
> You've previously described your workflow as one where you carefully
> integrate each feature branch separately into the integration
> branch.
But not in order, since not all features are developed on the
same time scale, or even in sequence. And so no, all feature branches
do not get integrated nicely in separate chunks and for the same
upstream version either.
> Do your commit messages in the integration branch not state what
> individual feature branch you're merging in?
Not usually. I describe the changes as it affects the
integration branch, and sometimes I mention which branch it came from.
> It seems to me that the analogue to a linear sequence of patches is
> the revision history of your integration branch. Granted, this doesn't
> give patches against a pristine upstream except from some initial
> state.
It does not even apply to the current version of upstream. If a
feature branch was developed over the course of a dozen or so upstream
versions, and intertwined with development on other feature branches,
the integration branch might give the sequence of merges, but will not
give a patch set that applies to any given upstream version, and you'll
have to retrace the exact sequence of merges and upstream updates -- in
other words, playing back the whole history of the package.
For make, for instance, the history stretches back over a decade.
manoj
--
I never vote for anyone. I always vote against. W.C. Fields
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]
