From: Willy TARREAU <willy@w.ods.org>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Willy TARREAU <willy@w.ods.org>,
Chuck Ebbert <76306.1226@compuserve.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Kernel source tree splitting
Date: Thu, 1 May 2003 16:43:16 +0200 [thread overview]
Message-ID: <20030501144316.GA1539@pcw.home.local> (raw)
In-Reply-To: <13900000.1051799746@[10.10.2.4]>
On Thu, May 01, 2003 at 07:35:48AM -0700, Martin J. Bligh wrote:
> >> 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
that's also what I do when I don't trust a script ;-)
> 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.
I didn't know about dupvi. But I admit that it's really easy to break the link
before starting vi, to ensure there's no problem.
> For added paranoia, I suppose you could make your "main" views (eg the
> unpatched ones) owned by another user.
this could help emacs because it tries every possibility to save a file, even
changing its rights if there's no other way.
> 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
and I thought it was dirty when I began to reach 50 links.... :-)
Cheers,
Willy
next prev parent reply other threads:[~2003-05-01 14:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-01 11:54 Chuck Ebbert
2003-05-01 14:06 ` Martin J. Bligh
2003-05-01 14:20 ` Willy TARREAU
2003-05-01 14:35 ` Martin J. Bligh
2003-05-01 14:43 ` Willy TARREAU [this message]
2003-05-01 15:01 ` Larry McVoy
2003-05-01 15:11 ` Martin J. Bligh
2003-05-01 17:22 ` Balram Adlakha
2003-05-01 17:28 ` Ben Greear
2003-05-01 20:03 ` John Bradford
-- strict thread matches above, loose matches on Subject: below --
2003-05-01 16:00 Chuck Ebbert
2003-04-30 23:46 rmoser
2003-05-01 0:21 ` Randy.Dunlap
2003-05-01 0:44 ` rmoser
2003-05-01 2:51 ` Randy.Dunlap
2003-05-01 10:13 ` rmoser
2003-05-01 0:52 ` Larry McVoy
2003-05-01 1:00 ` rmoser
2003-05-01 17:28 ` James H. Cloos Jr.
2003-05-01 4:10 ` Martin J. Bligh
2003-05-01 6:14 ` Ed Sweetman
2003-05-01 6:14 ` Peter Riocreux
2003-05-02 0:09 ` Randy.Dunlap
2003-05-02 0:41 ` rmoser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20030501144316.GA1539@pcw.home.local \
--to=willy@w.ods.org \
--cc=76306.1226@compuserve.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®