SVK::Command::Delete(3) User Contributed Perl Documentation SVK::Command::Delete(3)NAME
SVK::Command::Delete - Remove versioned item
OPTIONS -K [--keep-local] : do not remove the local file
-m [--message] MESSAGE : specify commit message MESSAGE
-F [--file] FILENAME : read commit message from FILENAME
--template : use the specified message as the template to edit
--encoding ENC : treat -m/-F value as being in charset encoding ENC
-P [--patch] NAME : instead of commit, save this change as a patch
-S [--sign] : sign this change
-C [--check-only] : try operation but make no changes
--direct : commit directly even if the path is mirrored
--force : delete the file/directory even if modified
perl v5.10.0 2008-08-04 SVK::Command::Delete(3)
Check Out this Related Man Page
SVK::Command::Patch(3) User Contributed Perl Documentation SVK::Command::Patch(3)NAME
SVK::Command::Patch - Manage patches
patch --ls [--list]
patch --cat [--view] PATCHNAME
patch --regen [--regenerate] PATCHNAME
patch --up [--update] PATCHNAME
patch --apply PATCHNAME [DEPOTPATH | PATH] [-- MERGEOPTIONS]
patch --rm [--delete] PATCHNAME
OPTIONS --depot DEPOTNAME : operate on a depot other than the default one
To create a patch, use "commit -P" or "smerge -P". To import a patch that's sent to you by someone else, just drop it into the "patch"
directory in your local svk repository. (That's usually "~/.svk/".)
svk patches are compatible with GNU patch. Extra svk-specific metadata is stored in an encoded chunk at the end of the file.
A patch name of "-" refers to the standard input and output.
"svk patch" command can help out on the situation where you want to maintain your patchset to a given project. It is used under the
situation that you have no direct write access to remote repository, thus "svk push" cannot be used.
Suppose you mirror project "foo" to "//mirror/foo", create a local copy on "//local/foo", and check out to "~/dev/foo". After you've done
some work, you type:
svk commit -m "Add my new feature"
to commit changes from "~/dev/foo" to "//local/foo". If you have commit access to the upstream repository, you can submit your changes
directly like this:
svk push //local/foo
Sometimes, it's useful to send a patch, rather than submit changes directly, either because you don't have permission to commit to the
upstream repository or because you don't think your changes are ready to be committed.
To create a patch containing the differences between "//local/foo" and "//mirror/foo", use this command:
svk push -P Foo //local/foo
The "-P" flag tells svk that you want to create a patch rather than push the changes to the upstream repository. "-P" takes a single flag:
a patch name. It probably makes sense to name it after the feature implemented or bug fixed by the patch. Patch files you generate will be
created in the "patch" subdirectory of your local svk repository.
Over time, other developers will make changes to project "foo". From time to time, you may need to update your patch so that it still
First, make sure your local branch is up to date with any changes made upstream:
svk pull //local/foo
Next, update your patch so that it will apply cleanly to the newest version of the upstream repository:
svk patch --update Foo
Finally, regenerate your patch to include other changes you've made on your local branch since you created or last regenerated the patch:
svk patch --regen Foo
To get a list of all patches your svk knows about, run:
svk patch --list
To see the current version of a specific patch, run:
svk patch --view Foo
When you're done with a patch and don't want it hanging around anymore, run:
svk patch --delete Foo
To apply a patch to the repository that someone else has sent you, run:
svk patch --apply - < contributed_feature.patch
perl v5.10.0 2008-08-04 SVK::Command::Patch(3)