1SVK::Command::Patch(3)User Contributed Perl DocumentationSVK::Command::Patch(3)
2
3
4
6 SVK::Command::Patch - Manage patches
7
9 patch --ls [--list]
10 patch --cat [--view] PATCHNAME
11 patch --regen [--regenerate] PATCHNAME
12 patch --up [--update] PATCHNAME
13 patch --apply PATCHNAME [DEPOTPATH | PATH] [-- MERGEOPTIONS]
14 patch --rm [--delete] PATCHNAME
15
17 --depot DEPOTNAME : operate on a depot other than the default one
18
20 To create a patch, use "commit -P" or "smerge -P". To import a patch
21 that's sent to you by someone else, just drop it into the "patch"
22 directory in your local svk repository. (That's usually "~/.svk/".)
23
24 svk patches are compatible with GNU patch. Extra svk-specific metadata
25 is stored in an encoded chunk at the end of the file.
26
27 A patch name of "-" refers to the standard input and output.
28
30 "svk patch" command can help out on the situation where you want to
31 maintain your patchset to a given project. It is used under the
32 situation that you have no direct write access to remote repository,
33 thus "svk push" cannot be used.
34
35 Suppose you mirror project "foo" to "//mirror/foo", create a local copy
36 on "//local/foo", and check out to "~/dev/foo". After you've done some
37 work, you type:
38
39 svk commit -m "Add my new feature"
40
41 to commit changes from "~/dev/foo" to "//local/foo". If you have commit
42 access to the upstream repository, you can submit your changes directly
43 like this:
44
45 svk push //local/foo
46
47 Sometimes, it's useful to send a patch, rather than submit changes
48 directly, either because you don't have permission to commit to the
49 upstream repository or because you don't think your changes are ready
50 to be committed.
51
52 To create a patch containing the differences between "//local/foo" and
53 "//mirror/foo", use this command:
54
55 svk push -P Foo //local/foo
56
57 The "-P" flag tells svk that you want to create a patch rather than
58 push the changes to the upstream repository. "-P" takes a single flag:
59 a patch name. It probably makes sense to name it after the feature
60 implemented or bug fixed by the patch. Patch files you generate will be
61 created in the "patch" subdirectory of your local svk repository.
62
63 Over time, other developers will make changes to project "foo". From
64 time to time, you may need to update your patch so that it still
65 applies cleanly.
66
67 First, make sure your local branch is up to date with any changes made
68 upstream:
69
70 svk pull //local/foo
71
72 Next, update your patch so that it will apply cleanly to the newest
73 version of the upstream repository:
74
75 svk patch --update Foo
76
77 Finally, regenerate your patch to include other changes you've made on
78 your local branch since you created or last regenerated the patch:
79
80 svk patch --regen Foo
81
82 To get a list of all patches your svk knows about, run:
83
84 svk patch --list
85
86 To see the current version of a specific patch, run:
87
88 svk patch --view Foo
89
90 When you're done with a patch and don't want it hanging around anymore,
91 run:
92 svk patch --delete Foo
93
94 To apply a patch to the repository that someone else has sent you, run:
95
96 svk patch --apply - < contributed_feature.patch
97
98
99
100perl v5.34.0 2022-01-21 SVK::Command::Patch(3)