Re: A modest proposal -- We need a patch penguin

[Keith Owens]

On Wed, 30 Jan 2002 22:07:20 -0800, 
Larry McVoy <[e-mail]> wrote:
>On Thu, Jan 31, 2002 at 05:03:11PM +1100, Keith Owens wrote:
>> My point is that full replication of history may be
>> too much detail for anybody except the original developer.  If bk can
>> consolidate a series of patchsets into one big patchset (not patch)
>> which becomes the unit of distribution then the problem of too much
>> history can be solved.
>
>If all you mean is that you don't want to have to tell it what to send,
>yes, it does that automatically.  If you start with 100 changes, 
>I clone your tree, you add 200 more, all I do to get them is say
>
>	bk pull
>
>it will send them all, quickly (works very nicely over a modem or 
>a long latency link like a satellite).

AFAICT this is the heart of Rob's problem.  He (and I) do not want you
to see all 200 changes.  Some changes are dead ends, some are temporary
bug fixes that I know will be replaced later, IOW they are my jottings,
not for public release.  Replicating the lot to everybody is just
polluting the other trees.

OTOH if I can tell bk :-

* Take all the changes in the direct line from 17.1 to 17.37.
* Ignore any extraneous branches off that line.
* Ignore other changes that were applied in the same time period but
  are not on the direct line, I am also making changes to 2.4.18-pre6
  at the same time.
* Generate a consolidated patchset which is visible to the outside
  world.
* Hide anything not explicitly marked as visible.
* When the consolidated patchset comes back from the master tree,
  recognise that it is equivalent to 17.1 through 17.37 on my tree,
  even though nobody else has the individual changes.

Then I can choose to make kdb v2.1 2.4.17 common-2 visible as an
entity (17.1 to 17.37), without telling everybody else what other
changes are going on in my tree.  bk pull only sees the consolidated
changes I want to make visible.