Re: Kernel source tree splitting
Martin J. Bligh (email@example.com)
Thu, 01 May 2003 07:35:48 -0700
>> 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
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 ;-)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/