Re: automated patch dependency and conflict tracking

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stefan Fiedler wrote:
> 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.

Hi Stefan.

First, it's a very nice script and indeed helpful.

But it would be even more helpful if it wouldn't just assume a sane environment
and being called directly.

Checks like

if [ -z "`which lsdiff`" ] ; then
	echo "lsdiff not found!" >&2
	echo "Please install the package 'patchutils'!" >&2
	exit 1
fi

would be nice :)
Also, you should check for command line arguments being sane (like the existence
of patches in the patchdir) as well as checking for -h --help -v --verbose switches.
This is a good start for that: http://shellscripts.org/project/template


Greetings,
	Benjamin
- --
 _  _     _   _            _
| \| |___| |_| |_  __ _ __| |__
| .` / -_)  _| ' \/ _` / _| / /
|_|\_\___|\__|_||_\__,_\__|_\_\
| |  (_)_ _ _  ___ __
| |__| | ' \ || \ \ /
|____|_|_||_\_,_/_\_\
Play Nethack anywhere with an x86 computer:
	http://www.crash-override.net/?nethacklinux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFD8LGPr0OTeImXvg8RAsk8AJ9FvCvbNQg4gJ0lEhXQ5evE+rr7QwCeJ2bh
t/B5Zuc9gL7ftzUcibPqeUU=
=Nkyu
-----END PGP SIGNATURE-----