Re: Kernel source tree splitting

[Martin J. Bligh]

>> -r--r--r--  1689 fletch   fletch      18691 Nov 17 20:29 COPYING
> 
> That's a bunch.  Who's fletch?  
> 
> And more importantly, how do you keep track of what is in each of those?
> I can see having 20, 100, whatever, and keeping it straight in your head
> but 1600?  

I have one view for every patch, and a bunch of scripts to manage them,
tear them down, build them up, and create patches from all of them in one
dir (they're a numbered sequence). A decent tree structure helps ;-)

It helps me to keep all the patches separated out - I want to be able to
carry forward 100 patches (at least) in sequence against the mainline tree,
and keep them all separate. Totally different problem from the one Linus
has, IMHO. 

I guess I have a view for what you call a changeset ... AFAICS, if you just
take 100 stacked patches, and do a merge forward through 30 versions, you
just end up with a big mess that you can't extract the real "changes"
you're making back out from the main view. But I've never really tried, it
might work out in BK or something I suppose. If that worked (in ~1 minute
for 100 patches), I'd be very tempted to try it (I hate learning curves for
new tools, half the time they're just burnt time).

> We'll still never be as fast as a pure hardlinked tree, that's balls to
> the wall as fast as you can go as far as I can tell.

Ow ;-)

M.