1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335
|
p is a tool for managing patches. It contains many
subcommands. To use a particular subcommand, give it
as the first argument to p, and then give any arguments
that subcommand requires
files
p keeps all it's files and patches in a subdirectory of
the toplevel directory of a project. This subdirectory
is called ".patches". It is often convenient for
".patches" to actually be a symbolic link to somewhere
else altogether.
The files and directories contained in .patches are:
applied/ A directory containing applied patches
removed/ A directory containing removed patches
include/ A directory containing included patches
Files in these directories are prefixed by a 3digit number
which indicate thr order in which patches were added.
The remainder of the filename is the name of the patch.
Each file contains:
Status: status
... notes ...
... diffstat output ...
the actual patch
name A file containing the name of the current patch
status A file containing the status of the current patch
notes A file with notes about the patch
patch A a recently generated copy of the current patch
files A list of files that are 'checked out'
to-resolve A list of files that might have conflicts that need resolving
tmp A temporary file
last-applied A most recently apply patch that had conflicts
last-purge
dest/ A directory where 'p publish' puts patch sets.
SOURCE/ A directory where a bk repository lives.
mail/ A directory of patches converted to email messages
cc A files listing: prefix name emailaddr
When mailing patches which start with prefix, name
is put on the subject line, and the mail is cc:ed to
emailaddr
maintainer This is where patches are mailed to
owner These mail headers are included in each mail message
get-version A script to get a base version number for use when publishing
to-resolve List of files have have outstanding conflicts to be resolved.
model
overview
What is 'p' ?
'p' is a patch management system, not a source code control system.
It allows you to create a set of patches against a base release, to
annotate those patches with comments, and to revisit and edit patches
after they have been committed.
It also allows you to update the base release that the patches are
against, and then re-apply all patches.
At any time, there are a number of applied patches, a number of
removed patches and possibly a current patch.
The sets of applied and removed patches act much like stacks. The current
patch can be moved to the top of either (commit or discard), and the top
of either patch can be moved to the current patch (open or apply).
open and apply actualy allow any patch in the corresponding stack to be
made current, and assume that the use won't re-order patches that
should not be re-ordered.
To enable 'p' for a project, you simply create a directory called ".patches"
in the top level directory of that project. Files should be checked out
("p co filename") before editing but never need to be checked in. Applying
and external patch automatically checks out all modified files.
Often it is appropriate to have the .patches directory elsewhere (for
example in an http-export directory tree for public access) and have a
symlink from .patches to that location.
p can be run from any subdirectory of a project containing a .patches
directory.
To find out about the contents of the .patches directory, see
p help files
Some common commands are:
p co filename # monitor changes to filename
p make # create and view the current patch
p commit # commit the current patch
p discard # discard current patch, saving it as
# a removed patch
p apply # re-apply a removed patch, or apply
# an external patch
p list # list current patches
co
Usage: p co filename
prepare filename for editing. This makes sure there is a
copy of the file with a ~current~ suffix, and that the file
is listed in in .patches/files. This command can be run from
a subdirectory of the project, and it will still do the
right thing.
make
view
Usage: p make
p view [patchnamefragment]
make and view provide the same functionality.
When given a patch name fragment, they will allow the unique
patch with that name (either applied or removed) to be viewed
(using the pager $PAGER, or less).
Without an argument, the current patch is calculated and
displayed. This explains the two names as with no argument,
they both make, and view the current patch.
all
Usage: p all
Generate a composite patch of all currently applied patches.
This involves creation a patch from the ~orig~ version of every
file to it's current version.
status
name
Usage: p status [newstatus]
p name [newname]
If a new status or name is given, it is recorded as the current
status or name for the current patch. If no argument is given,
the command will prompt for both a new name and a new status.
The current value is offered as a default in each case.
note
notes
Usage: p notes
Open the notes describing the current patch in an $EDITOR
The notes should contain a simple one-line description,
a black line, and then a detailed description.
discard
Usage: p discard
The current patch is discard: moved to the .patches/removed
directory. If it doesn't have a name or status, these are
prompted for.
commit
Usage: p commit
The current patch is commit: moved to the .patches/applied
directory. If name or status aren't set, these are prompted
for. If no notes have been written, and $EDITOR session is
started with a template for some notes.
The patch is presented in the file being edited for reference,
but will be removed from the notes on exit.
open
Usage: p open [last | patch-name-fragment]
The open command is used to open a previously commited
patch for further editing.
Without any argument, a list of available commited patches
is given.
If the argument 'last'is given, then the most recently commited
patch is opened.
Otherwise a unique patch with a name containing the name fragment
is openned. If there is no such unique patch, and error message
is given.
included
Usage: p included [-f] [last | patch-name-fragment]
After updating the base release of a project, some of the patches
which are currently "removed" may already have been included in that
release and so don't need to be maintained any more.
The "included" command will check if a given patch appears to have
been included and if so, moves it to the .patches/included directory.
The test is performed by seeing if 'patch' is able to remove the
patch. If it cannot, but you are sure that the patch has been included
(the problems patch reports are spurious) then using '-f' will cause
the patch to be moved to 'included' anyway.
list
Usage: p list
List all the patches in either 'applied' or 'removed'.
apply
Usage: p apply [-f] [-a] [last | patch-name-fragment | filename]
This command is used for applying a patch to the project.
If a patch in 'removed' is given, then it is moved out of 'removed'
and is applied. If a filename is given, the patch in that file is
applied but the file is left unchanged.
When applying a patch, all affected files are checked-out first.
If 'patch' cannot apply the patch without error, 'apply' will fail.
Giving the '-f' option will cause 'apply' to apply the patch anyway,
and then run 'wiggle' to merge any rejected patch chunks as best
as possible. Any files for which wiggle finds unresolvaable conflicts
while have its name saved in a file (.patches/to-resolve). This
list is used by the 'p resolve' command.
Normally, 'apply' will not apply a patch to be applies if there is
one already open. However the '-a' option may be given to ask
'apply' to "append" the patch to the current patch.
resolve
Usage: p resolve
This is used to resolve any conflicts found by wiggle. Each file
listed in .patches/to-resolve is presented for editing, and then
has wiggle run over it again to check that all conflicts have
been resolved.
publish
Usage: p publish
The 'publish' command will create a new subdirectory of
.patches/dest
(which is often a symlink to a web-page area) and copy
all current applied and removed patches into that directory.
It also creates a complete patch (with "p all") and stores
that in the directory.
clean
Usage: p clean
clean checks that no patches are currently applied, and
cleans up any ~current~ or ~orig~ files that have been left
in the source tree. It also removed write permission from
all checked-out files.
It effectively undoes all check-outs.
It is run as part of 'update' which incorporates upstream
changes into a source tree.
openall
Usage: p openall
This command repeatedly runs "p open last && p discard" until
that fails, which usually means that all patches have been
discarded. This is part of the preparation for incorporating
upstream changes.
recommit
Usage: p recommit patchname
This command will re-apply and re-commit removed patches
that successfully apply until the names patch has been applied.
Patches are applied in reverse order, which is consistant with
the order in which they were removed.
snapshot
Usage: p snapshot
This command takes a shapshot of the current patch so that further
work can be done in the patch, but it can easily be removed if
there are problems.
This might be used before appending a patch incase something goes
wrong in the appending process.
snapdiff
Usage: p snapdiff
Display the differences between the latest snapshot and the current
source.
snapback
Usage: p snapback
Revert all changes since the last snapshot
pull
Usage: p pull
Update the local copy of the official source repository. This
can be found by following the .patches/SOURCE link.
Currently the code assumes it is a BitKeeper repository and
runs "bk pull". It should be enhanced to recognise CVS and
run "cvs update".
update
Usage: p update
This command updates the based release of the package. To
do this it removes all patches (p openall), cleans up (p clean),
creates a patch from information in .patches/SOURCE, and applies
that patch. It currently makes no attempt to re-apply any
patches, or to "p included" and patches.
Currently the code assumes a BitKeeper repository and uses
"bk export -tpatch -rLASTEST," to extract a patch, and then
retags the repository with "bk tag LATEST". It should be
enhanced to recognise and work with CVS as well.
premail
Usage: p premail [patch-name-prefix]
This command converts a selection of patches to Email messages.
The email messages are stored in .patches/mail.
SAY MORE HERE
nomail
Usage: p nomail
Remove the .patches/mail directory and contents.
email
Usage: p email
Send all mail messages in .patches/mail. On success, each
email message is removed.
help
Usage: p help [topic]
Print out help messages, which are contained in a file
p.help
in the same directory that p was run from.
Without a topic, a general introduction and a list of topics
is presented. With a topic, help on that topic is presented.
purge
Usage: p purge
Make copy of the current patch in .patches/last-purge (just
in case) and then purge the current patch complete.
|