From 8bfc5756fb68e0b13d7e7c0073ad5b9a4790d1b6 Mon Sep 17 00:00:00 2001 From: rmanfredi Date: Thu, 24 Aug 2006 12:32:52 +0000 Subject: Moving project to sourceforge. git-svn-id: https://dist.svn.sourceforge.net/svnroot/dist/trunk/dist@1 190e5f8e-a817-0410-acf6-e9863daed9af --- pat/README | 120 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 pat/README (limited to 'pat/README') diff --git a/pat/README b/pat/README new file mode 100644 index 0000000..20e15ec --- /dev/null +++ b/pat/README @@ -0,0 +1,120 @@ +This is the root directory for pat tools. + +This directory contains an automatic patch generator. You must have RCS +to use this. You must also have run packinit in the top level directory +of your package to create a .package file. + +When you've modified a file in your package, the pat program is used to +control the whole process. The other programs can be called by hand, but +usually needn't be. Run pat from the top level directory of your package. + +The pat, patcil, patdiff, and patbase programs take a list of filenames as +arguments. Alternately, a -a means all files listed in MANIFEST. + +Patcil will create an RCS directory if necessary. However, it may not check in +things which require special initializaton properly. For example, if you +want to check in a shell script, you'd better make your RCS directory yourself +and then say + + rcs -i -c'# ' blurfl.xsh + +before running pat or patcil. Otherwise the RCS log may not be commented +properly. Unless of course you are using a standard extension (like .c for +a C file) or have placed the proper comments in front of the $Log marker +within the file itself--patcil will then correctly guess the type of +comment required. + +Patdiff will create a bugs directory in your top level directory, and will want +to find a patchlevel.h file in that same directory. Everything is done from +that top level directory--don't put any patchlevel.h or bugs directories in +your subdirectories. Each subdirectory has its own RCS directory though. + +Patpost, patsend and patftp may be used to post to Usenet, mail to someone, +or copy patches to your ftp directory. They take a destination and a list +of patches to process. + +Those pat tools are an hopefully enhanced version of the tools that +came with Larry Wall's dist 2.0. There are however a few new scripts: + + - patclean, which checks in the mods and removes the working files. + - patcol, which restores the files removed by a patclean. + - patname, which sets a symbolic version number. + +Here is the way I am using the pat tools... + +First, I set up a MANIFEST.new file. If you are converting an existing +distribution to use dist, the manifake script will convert a MANIFEST +into a MANIFEST.new (removing the possible archive number column). + +Then I run packinit to modify the version number and set up things +correctly. The package is then ready to be placed under pat control. +I make sure the file patchlevel.h is correctly set and I run: + + patcil -f -a -s + touch patchlevel.h + find . -name "*~" -exec /bin/rm -f {} \; -print + +There is a prototypical patchlevel.h file in this directory, so you +might want to have a look at it. + +[If you are planning on using the mailagent to send the patches (and sort +your mail -- that's its primary goal now), the you must make sure +the patchelevel.h file is locatated in the root directory of your package. +The mailagent program is available separately, and was posted on the +comp.sources.misc newsgroup] + +Now everything is ready. The distribution is frozen, the bugs directory +has been created. I issue a makedist -v to create the distribution kits. +Eventually I set up the mailagent so that people can request for the +distribution automatically. If I want to create a directory containing +the lattest sources (to be able to `kit' them to someone using the kit +program -- posted to comp.sources.unix), I use: + + makedist -c -@ + +for instance, for dist 2.9 at PL26 + + makedist -c dist-2.9@26 + +which I can then send to people directly with kit (which is NOT part +of this release). + +As I receive patches or find some bugs, I edit the files and make the +modifications. When I want to issue an official patch, I run: + + pat -n + +and one or more patches are issued. You can compress the patches in the +bugs subdirectory, since the mailpatch program knows about that. Also +patindex will correctly uncompress them. + +When I need to clean up the distribution directory, I use: + + patclean -a + +which checks in every changes and removes the working files. The whole +set of working files can then be restored by: + + patcol -a + +Sometimes, I made a couple of modification and I don't want to issue +a patch right now. I then run: + + patcil -a + +which checks in the changes. You can run this as many times as you want, +because patcil will skip unchanged file and remembers the last time you +issued a patch. + +If you are still using RCS 4.3, be sure you use makedist and not your +own shell archiver, as the $Locker symbol has an annoying expansion +which makes patch to fail when applyed. I'm not sure this was correctly +fixed with RCS 5.5 as I am not using it yet for various reasons. + +In any case, if you are using the copyright expansion feature (i.e. the +stuffing of the COPYRIGHT token surrounded by '@' -- can't do it here +or it will get expanded...), then you must use makedist to make sure +the copyright is properly written in all your files. Distributing files +with an un-expanded COPYRIGHT token in them would be a disaster, since +the patching system will also expand them before building a patch and +some of your hunks may not apply correctly. -- cgit v1.2.3