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

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

NAME

       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

GIT-PATCH-ID(1) 						    Git Manual							   GIT-PATCH-ID(1)

NAME

       git-patch-id - Compute unique ID for a patch

SYNOPSIS

       git patch-id [--stable | --unstable]

DESCRIPTION

       Read a patch from the standard input and compute the patch ID for it.

       A "patch ID" is nothing but a sum of SHA-1 of the file diffs associated with a patch, with whitespace and line numbers ignored. As such,
       it's "reasonably stable", but at the same time also reasonably unique, i.e., two patches that have the same "patch ID" are almost
       guaranteed to be the same thing.

       IOW, you can use this thing to look for likely duplicate commits.

       When dealing with git diff-tree output, it takes advantage of the fact that the patch is prefixed with the object name of the commit, and
       outputs two 40-byte hexadecimal strings. The first string is the patch ID, and the second string is the commit ID. This can be used to make
       a mapping from patch ID to commit ID.

OPTIONS

       --stable
	   Use a "stable" sum of hashes as the patch ID. With this option:

	   o   Reordering file diffs that make up a patch does not affect the ID. In particular, two patches produced by comparing the same two
	       trees with two different settings for "-O<orderfile>" result in the same patch ID signature, thereby allowing the computed result
	       to be used as a key to index some meta-information about the change between the two trees;

	   o   Result is different from the value produced by git 1.9 and older or produced when an "unstable" hash (see --unstable below) is
	       configured - even when used on a diff output taken without any use of "-O<orderfile>", thereby making existing databases storing
	       such "unstable" or historical patch-ids unusable.

		   This is the default if patchid.stable is set to true.

       --unstable
	   Use an "unstable" hash as the patch ID. With this option, the result produced is compatible with the patch-id value produced by git 1.9
	   and older. Users with pre-existing databases storing patch-ids produced by git 1.9 and older (who do not deal with reordered patches)
	   may want to use this option.

	       This is the default.

GIT

       Part of the git(1) suite

Git 2.17.1							    10/05/2018							   GIT-PATCH-ID(1)

Linux and UNIX Man Pages

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

Check Out this Related Man Page