-
Notifications
You must be signed in to change notification settings - Fork 8
/
p.help
335 lines (260 loc) · 11.4 KB
/
p.help
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.