On Mon, 25 Feb 2008 09:35:13 +0100, martin f krafft <[EMAIL PROTECTED]> said:
> also sprach Manoj Srivastava <[EMAIL PROTECTED]> [2008.02.25.0828
>> 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.
> The tool I envision would simply surf through the history of the
> integration branch and identify merge commits. Each merge would become
> a patch in the quilt series.
How are you planning on doing this identification? Looking at
the arch logs, it is not trivial to identify merge commits and the
upgrade patches (which are just merges from the upstream branch),
unless you start with an ancient version (like, from my 2003 repo) and
then apply every single commit to the integration branch over the last
five years (with really really huge numbers of patches).
You'll have to track repo changes, figure out how to overcome
sealed branch boundaries, etc.
I am not sure I believe this to be feasible until I see some
>> 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 use.
> Except that quilt provides the necessary glue to handle it, while
> feature branches don't.
No, it does not. If branch A has
pi = 2.34567;
and branch B has
pi = 3.14159;
No matter how much quilting you do you cannot reconcile the
fundamental conflict in the final. Either pi is 3.14159; or it is not;
and if branch A requires pi not to be that value, and branch B requires
pi to be that value, quilt can't make C be quantum like and have the
value be both.
Griffin's Thought: When you starve with a tiger, the tiger starves last.
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