On Fri, Feb 01, 2002 at 11:29:58AM +1100, Keith Owens wrote:
> That sounds almost like what I was looking for, with two differences.
>
> (1) Implement the collapsed set so bk records that it is equivalent to
> the individual patchsets. Only record that information in my tree.
> I need the detailed history of what changes went into the collapsed
> set, nobody else does.
>
> (2) Somebody else creates a change against the collapsed set and I pull
> that change. bk notices that the change is again a collapsed set
> for which I have local detail. The external change becomes a
> branch off the last detailed patch in the collapsed set.
This is certainly possible to do. However, unless you are willing to fund
this development, we aren't going to do it. We will pick up the costs of
making changes that you want if and only if we have commercial customers
who want (or are likely to want) the same thing. Nothing personal, it's
a business and we make tradeoffs like that all the time.
Collapsing is relatively easy, it's tracking the same content in two
different sets of deltas which is hard to get exactly correct. Certainly
possible but I can visualize what it would take and it would be messy and
disruptive to the source base for an obscure feature that is unlikely to
be used.
Why don't you actually use BK for a while and see if you really think
you need this feature. The fact that our customers aren't clamoring for
it should tell you something. They do work as hard and on as much code
(in many cases on the same code) as you do.
-- --- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jan 31 2002 - 21:01:41 EST