automated patch dependency and conflict tracking

Hi all!

So I've finally worked something out: a shell script that can test-apply a 
large set of patches against a given directory and detect all dependencies 
and conflicts between patches.

It's main features are:
        * independent of any certain patch format: it solely relies on 
patchutils to perform tests
        * does not rely on patches being pre-sorted
        * does not modify any files, all tests are done in a (partial) 
on-the-fly copy of the directory
        * it is fast! It takes about 32 seconds on my Athlon XP 2000+ to 
test-apply 193 patches from SubMaster against trunk rev.6945
        * it detects alternative patches, e.g. when patch b would apply if 
patch a1 or patch a2 were applied
        * it detects if a patch depends on several patches which themselves 
don't depend on each other
        * it detects conflicts, where one patch does not apply when another is 
already applied
        * it writes test results to an easy to parse log file for 
postprocessing

How to use it:

        Patch-Groups [ -patchdir $pd ] [ -basedir $bd ] [ -outdir $od ] [ -p 
$p0 ]

It will test-apply all *.patch files in $pd to (a copy of) the directory $bd. 
$pd, $bd and $od must be absolute filenames. The defaults are "sm-patches", 
"`dirs`" and "outdir".
Patches are supposed to apply with the "-p$p0" patch option ("-p0" is the 
default).
Patch filenames must not contain white-space, and currently no patch name must 
be a part of another patch name (abc.patch and bc.patch is bad). 
fixdiff_*.patch files are ignored.
All output and temporary files will be written to $od. 

WARNING: everything in "outdir" ($od) will be deleted!

What to expect:

You can ignore the console output of the script. It is only used for 
debugging. 
Test results will end up in $outdir/patchtests-dep.out and 
$outdir/patchtests-indep.out.
Each line is of the form:
        
        $P: $F: $details $testresult

"$P: $F: " means the part of patch $P that affects file $F. $testresult (at 
the end of the line) may be one of ?, +, ~, # meaning:

        ? this part does not apply without another patch
        + this part applies (with another patch)
        ~ this part depends on other patch parts (listed in $details)
        # this part conflicts with another patch part (listed in $details)

If there is more than one ~ line for a certain patch part, each is an 
alternative way to make that part apply.

When Patch-Groups has finished, it's output can be fed to e.g. 
Patch-Report:
        
        Patch-Report [ -outdir $od ]

This little sample script will reorder patches so that all dependencies are 
met. Additionally it will summarize the test results: it will list all parts 
that failed to apply and which can be fixed in arbitrary order. Then it will 
list all non-applicable parts of the other patches, in the order they should 
be applied, together with dependencies and conflicts for that parts.
This way you get to see exactly what will happen if you apply the patches in 
this order to the $bd directory.

Of course the possibilities don't end here: a semi-automated patch-fixup could 
be run based on test results (e.g. check for reversed patches, "-p1" patches. 
conflicts caused by copyright note updates and [P] tags, ...).

I'd especially favor the use of test results in the SubMaster server side: 
dependency lists could be largely automated (note that "semantic" 
dependencies can't be autodetected), conflicts could be detected 
automatically, and you'd see right on spot which parts of a patch don't apply 
at all.

Bottom Line:

Your comments are very welcome! You might want to give the script a try and, 
for example, test-apply a set of patches from SubMaster to current trunk. 
I've attached two simple self contained test-cases. 
The set of 193 patches that were pending for trunk rev. 6945 follows in a 
separate mail (because of it's size).
If something remains unclear about the operation of the script, please take a 
look inside before asking. It is fairly well documented.

With best regards,
        Stefan Fiedler

_______________________________________________
rock-devel mailing list
[email protected]
http://www.rocklinux.net/mailman/listinfo/rock-devel