On Sun, 24 Feb 2008 11:04:21 +0100, martin f krafft <[EMAIL PROTECTED]> said: 

> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.22.1627
> +0100]:
>> 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]]

> well, I know what feature branches are but I suppose I jumped the
> gun. They are independent until you integrate them. But you will
> integrate them, thus I tend to think of them as interdependent from
> the start.

        You have a strange definition of interdependent.  The majority
 of my feature branches are really orthogonal;  seldom on integration
 there is no conflict; so it is hard for me to think of them as somehow
 inter dependent. Sure, there are overlapping changes, sometimes, but
 these are mostly one time resolution issues.

> Anyway, we're not talking about developing with quilt. We are talking
> about converting feature branches to quilt patches for the sake of
> representation in the source package. I don't see why you would oppose
> to that at all, to be honest.

        I am not opposed to it. If you can somehow magically create a
 tool that can linearize the feature branches, more power to you. I
 personally find the prospect highly unlikely; and I would like to see
 some code, please, before I grant that such a thing is possible.

>> 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.

> ... except when one feature needs to change and then conflicts with
> another feature on re-integration.

        Sure. You can't integrate two features that fundamentally
 conflict with each other. No amount of smoke and mirrors can obscure
 that fundamental obstacle. This is independent of the tool set you

>> B) Development happens on the feature 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.

> No, every time you do development on the branch. And every time, you
> have to remember which branch dependended/conflicted on the feature
> branch you're currently working on, or figure it out by trial and
> error. I don't consider this efficient. This is work that a computer
> should be doing.

        Strange. In all my years of using feature branches, I have never
 had to consider which branch depended on what. So no, I don't think I
 _have_ to remember any  such thing; trust me, I would have noticed.  I
 have 30+ packages, and have been using feature branches since  early
 this decade.

        If you have a whole slew of features that depend on other
 features, then your feature set is very different from ones I have
 encountered. Dependent features do require more work; but not as much,
 in my opinion, as using quilt or dpatch; but your mileage may vary.

        For the most part, I just develop on each branch independently.
 I compile, test, hack, compile, on each individual featre branch. And
 never ever worry about what the other feature branches are like, while
 doing so.

        Once in a blue moon (more or less) I have to deconflict the
 integration branch; but mostly those are swiftly resolved issues. And
 once resoved, I tend to forget about them too.  All this worrying about
 branch conflicts seem to be more the realm of quilt and other patch
 series mechanisms; which is mostly my reason to dislike them.

(It is an old Debian tradition to leave at least twice a year ...) Sven
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C
vcs-pkg mailing list

Reply via email to