Index of /pub/linux/kernel.org/kernel/people/mbligh/tools/patch

Icon  Name                                              Last modified      Size  Description
[PARENTDIR] Parent Directory                                                       -   
[   ] sha256sums.asc                                    2023-04-26 06:12  1.7K  
[   ] dupview                                           2004-05-22 07:48  253   
[   ] splatpatches                                      2004-05-06 05:56  1.3K  
[TXT] releasemjb                                        2004-04-30 03:39  2.1K  
[TXT] releasemjb.old                                    2004-02-21 16:52  1.9K  
[   ] creatediffs                                       2003-12-31 09:16  188   
[   ] linuxdiff                                         2003-12-31 09:02   48   
[TXT] README                                            2003-12-30 07:20  2.1K  
[   ] diffview                                          2003-07-31 06:32  810   
[   ] dupfile                                           2003-07-30 07:16  130   
[   ] duppatchview                                      2003-07-30 05:23   52   
[   ] applypatches                                      2003-07-30 05:16  795   

> Martin, do you use any scripts to manage your patchset?  The format of
> your mail looks similar to Andrew's, maybe you both use the same thing?

Yeah, I just make a bunch of hardlinked views, and some little wrapper
scripts. They're all here:

ftp://ftp.kernel.org/pub/linux/kernel/people/mbligh/tools/patch/

Basically, I have a directory strucuture that looks like this:

~/linux/patches/2.6.0
~/linux/patches/2.6.0-mjb1
~/linux/patches/2.6.0-mjb2

then

~/linux/views/2.6.0/virgin
~/linux/views/2.6.0-mjb2/000-virgin          (just a clone of the above)
~/linux/views/2.6.0-mjb2/100-netdrvr_2.6.0_exp3
...
~/linux/views/2.6.0-mjb2/630-lockmeter_notsc
~/linux/views/2.6.0-mjb2/999-mjb

So 000-virgin is the virgin kernel, 100-foo has patch 100-foo in it,
101-bar has 100-foo & 101-bar, etc, etc.

When 2.6.1 comes out I do something like this:

cd ~/linux/views
mkdir 2.6.1
mkdir 2.6.1-mjb1 
dupview 2.6.0/virgin 2.6.1/virgin
cd 2.6.1/virgin
bzcat ~mirror/kernel/v2.6/patch-2.6.1.bz2 | patch -p1
cd ../..
dupview 2.6.1/virgin 2.6.1-mjb1/000-virgin
cd 2.6.1-mjb1
applypatches ~/linux/patches/2.6.0-mjb1/[0-9]*
<wait for a patch to reject ... say it breaks on 240-foo, it'll stop>
cd 240-foo
<fix the rejects>
cd ..
applypatches ~/linux/patches/2.6.0-mjb1/2[5-9]*
applypatches ~/linux/patches/2.6.0-mjb1/[3-9]*

then if I run the releasemjb script, it generates all the new diffs, 
and uploads them to kernel.org for me. Cloning views is pretty fast,
though it's slower on ext3. I like having the numbering system, rather
than Andrew's series file for ordering stuff, though having all the 
views is probably less efficient than Andrew's. I guess the main benefit 
is that it's simple, and I understand exactly what it's doing.

Oh, and I use the "dupvi" script to edit files - it just breaks the
link first. All linked files are auto-chmod'ed to read only so it's
harder to make a mistake, and edit both views at once. It could probably
do with some tweaking, ie instead of 

applypatches ~/linux/patches/2.6.0-mjb1/2[5-9]*
applypatches ~/linux/patches/2.6.0-mjb1/[3-9]*

it should somehow do

applypatches from ~/linux/patches/2.6.0-mjb1/250

and know that means to apply the rest on upwards.