Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

svk::command::patch(3) [osx man page]

SVK::Command::Patch(3)					User Contributed Perl Documentation				    SVK::Command::Patch(3)

SVK::Command::Patch - Manage patches SYNOPSIS
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 DESCRIPTION
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. INTRODUCTION
"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 applies cleanly. 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)

Check Out this Related Man Page

SVK::Command::Info(3)					User Contributed Perl Documentation				     SVK::Command::Info(3)

SVK::Command::Info - Display information about a file or directory SYNOPSIS
-R [--recursive] : descend recursively DESCRIPTION
For example, here's the way to display the info of a checkout path: % svk info ~/dev/svk Checkout Path: /Users/gugod/dev/svk Depot Path: //svk/local Revision: 447 Last Changed Rev.: 447 Last Changed Date: 2006-11-28 Copied From: /svk/trunk, Rev. 434 Merged From: /svk/trunk, Rev. 445 You can see the result has some basic information: the actual depot path, and current revision. Next are advanced information about copy and merge source for this depot path. The result of "svk info //svk/local" is almost the same as above, except for the "Checkout Path:" line is not there, because you are not referring to a checkout path. Note that the revision numbers on "Copied From:" and "Merged From:" lines are for the source path (//svk/trunk), not the target path (//svk/local). The example above state that, //svk/local is copied from the revision 434 of //svk/trunk, and //svk/local was merged from the revision 445 of //svk/trunk. Hence if you do a "svk log -r 434 //svk/local", svk would tell you that //svk/local does not exist at revision 434. So far there is no easy way to tell the actual revision number of //svk/local right after a copy or merge. If the target is a depot path, or the corresponding depot path of the target checkout path is actually a mirroring path, the output of this command will look like this: % svk info //svk/trunk Depot Path: //svk/trunk Revision: 447 Last Changed Rev.: 445 Mirrored From: svn://, Rev. 1744 So you can see this depot path is mirrored from a remote repository, and so far mirrored up to revision 1744. perl v5.10.0 2008-08-04 SVK::Command::Info(3)
Man Page