Re: Kernel source tree splitting

[Martin J. Bligh]

>> Indeed. But whilst you're waiting, hardlink everything together, and 
>> patch the differences (patch knows how to break hardlinks). Make a 
>> script that cp -lR's the tree to another copy (normally takes < 1s), and
>> then remove the other arches. grep that.
> 
> I agree with Martin here, I always use hardlinks, and when I have too many
> kernel trees, I even recompact them by diff/rm/cp -l/patch to get as small
> differences as possible. You can have tens of kernels in less than 400 MB,
> and tools such as diff and grep are really fast because it's easy to keep
> several kernels in the cache.
> 
> The only danger is to modify several files at once with stupid operations
> such as "cat $file.help >> Documentation/Configure.help" which are
> sometimes included in some scripts. It would be cool to be able to lock
> the source, but I never found how (perhaps I should try chattr+i ?). And
> I don't know how to force vi and emacs to unlink before saving, so I have
> to be careful before certain operations. But all in all, it's extremely
> useful.

find -type f | xargs chmod ugo-w 

whenever you make a new copy seems to work pretty well to me. 
Then you use "dupvi" to edit the files, which is just a little wrapper that
breaks the link, and edits the file. 

For added paranoia, I suppose you could make your "main" views (eg the
unpatched ones) owned by another user. But I've never had a problem with
just chmod, and I have a lot of views ... 1689 all linked together ;-)

-r--r--r--  1689 fletch   fletch      18691 Nov 17 20:29 COPYING

Oh, and diff of views takes < 1s (diff understands hardlinks too, it seems).
Any SCM can kiss my ass ;-)

M.