|
Size: 5049
Comment:
|
Size: 7522
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| == Perfarce Extension == | #pragma section-numbers 2 = Perfarce Extension = |
| Line 6: | Line 7: |
| Public repository: http://www.kingswood-consulting.co.uk/hg/perfarce | Repository: http://hg.kingswood-consulting.co.uk/perfarce |
| Line 8: | Line 9: |
| === Overview === This extension modifies the remote repository handling so that repository paths that resemble p4://p4server[:port]/clientname |
<<TableOfContents>> == Overview == This extension modifies the remote repository handling so that repository paths that resemble . p4://p4server[:port]/clientname |
| Line 14: | Line 18: |
| The client specification must already exist on the server before using this extension, and the working copy belonging to this client spec must be visible to hg. |
The client specification must already exist on the server before using this extension, and the working copy belonging to this client spec must be visible to hg as Root or one of the !AltRoots in the client spec. If configuration keep=true then it is possible to share this working copy with local p4 operations. Note that the p4 and Mercurial workspaces should never overlap. |
| Line 18: | Line 20: |
| == Commands == {{{ hg clone [--startrev REV] [-r REV] [p4://server/clientname] }}} If the source repository name starts with p4:// then this creates the destination repository and pulls all changes from the p4 depot into it. The --startrev and -r options set the first and last p4 changelist to pull. Setting a start revision causes the contents of all files at that changelist to be included in the first converted revision. There must be at least two revisions to clone if --startrev is set. After the clone is complete the Perfarce extension will write a ''`.hg/hgrc`'' file with the p4 address and the configuration options in use. |
|
| Line 19: | Line 26: |
| === Commands === | {{{ hg incoming [p4://server/clientname] }}} If the source repository name starts with p4:// then this reports changes in the p4 depot that are not yet in the local repository. |
| Line 21: | Line 31: |
| outgoing If the destination repository name starts with p4:// then this reports files affected by the revision(s) that are in the local repository but not in the p4 depot. |
{{{ hg pull [-r REV] [p4://server/clientname] }}} If the source repository name starts with p4:// then this imports changes from the p4 depot, automatically creating merges of changelists submitted by hg push. The -r option sets the last p4 changelist to pull. If the perfarce.keep configuration is false then the import does not leave files in the p4 workarea, otherwise the p4 workarea will be updated with the new files. |
| Line 25: | Line 36: |
| push If the destination repository name starts with p4:// then this exports changes from the local repository to the p4 depot. If no revision is specified then all changes since the last p4 changelist are pushed. In either case, all revisions to be pushed are folded into a single p4 changelist. Optionally the resulting changelist is submitted to the p4 server, controlled by the --submit option to push, or by setting --config perfarce.submit=True If the option --config perfarce.keep=False is False then after a successful submit the files in the p4 workarea will be deleted. |
{{{ hg outgoing [p4://server/clientname] }}} If the destination repository name starts with p4:// then this reports files affected by the revision(s) that are in the local repository but not in the p4 depot. |
| Line 39: | Line 41: |
| pull If the source repository name starts with p4:// then this imports changes from the p4 depot, automatically creating merges of changelists submitted by hg push. If the option --config perfarce.keep=False is False then the import does not leave files in the p4 workarea, otherwise the p4 workarea will be updated with the new files. The option --config perfarce.clientuser=search replace can be used to enable quasi-multiuser operation, where several users submit changes to p4 with the same user name and have their real user name in the p4 client spec. The search and replace regular expressions describe the substitution to be made to turn a client spec name into a user name. If the search regex does not match then the username is left unchanged. |
{{{ hg push [-r REV] [--submit] [p4://server/clientname] }}} If the destination repository name starts with p4:// then this exports changes from the local repository to the p4 depot. If no revision is specified then all changes since the last p4 changelist are pushed. In either case, all revisions to be pushed are folded into a single p4 changelist. Optionally the resulting changelist is submitted to the p4 server, controlled by the --submit option to push, or by the perfarce.submit configuration. If the perfarce.keep configuration is false then after a successful submit the files in the p4 workarea will be deleted. |
| Line 57: | Line 46: |
| incoming If the source repository name starts with p4:// then this reports changes in the p4 depot that are not yet in the local repository. |
{{{ hg p4id [-c CL] [-r REV] [-nip] }}} Shows the most recent or selected P4 changelist known to Mercurial, or the P4 changelist associated with Mercurial revision REV. The -n -i and -p options cause the local revision number, the global revision id and the p4 changelist number to be displayed. |
| Line 61: | Line 51: |
| clone If the source repository name starts with p4:// then this creates the destination repository and pulls all changes from the p4 depot into it. If the option --config perfarce.lowercasepaths=False is True then the import forces all paths in lowercase, otherwise paths are recorded unchanged. Filename case is always preserved. This setting is a workaround to handle Perforce depots containing a path spelled differently from file to file (e.g. path/foo and PAth/bar). |
{{{ hg p4pending [-s] }}} Shows pending changes, those that have been pushed and possibly submitted, but not yet pulled from p4. If the -s option is given, then the pending changelists are presented in a long format with summaries of the changelist comment. |
| Line 73: | Line 56: |
| === Configuration === Configure your .hgrc to enable the extension by adding following lines: |
{{{ hg p4submit [-a] [changelist] }}} Submit a changelist to p4. If the -a option is given then all changes that have been pushed will be submitted. {{{ hg p4revert [-a] [changelist] }}} Delete a changelist from p4, reverting any file changes. If the -a option is given then all changes that have been pushed but not submitted will be reverted. == Configuration == Configure your ''`.hgrc`'' to enable the extension by adding following lines: |
| Line 79: | Line 72: |
| }}} | |
| Line 81: | Line 73: |
{{{ |
|
| Line 86: | Line 76: |
| tags = True | |
| Line 87: | Line 78: |
| ignorecase = False | |
| Line 88: | Line 80: |
| encoding = ascii maxargs = 250 copy = False move = False |
|
| Line 89: | Line 85: |
If the '''keep''' option is true (this is default) then the Perfarce extension will keep the p4 workarea updated with the current top of tree in Perforce. If '''keep''' is false then the Perfarce extension does not leave files in the p4 workarea unless it is creating a changelist. If the '''submit''' option is true then Perfarce will automatically submit a changelist when pushing changes to the p4 depot. The default is to create a pending changelist, and let the user review this before submitting, either with p4 submit or hg p4submit. If the '''lowercasepaths''' option is true then the Perfarce extension forces all directory names received from p4 to lowercase, but leaving filenames unchanged. The default is to preserve filenames. The '''clientuser''' option allows for 'cheap' multiuser operation with Perforce. The option argument is split on the first space into a search regular expression and a replacement string. If the regular expression matches the client spec name of an imported p4 changelist then the username for the changelist is changed to the value of the replacement string after it is capitalized. The replacement string can use regex matches to substitute part of the client spec name.An example could be |
The '''clientuser''' option allows for 'cheap' multiuser operation with p4. The option argument is split on the first space into a search regular expression and a replacement string. If the regular expression matches the client spec name of an imported p4 changelist then the username for the changelist is changed to the value of the replacement string after it is capitalized. The replacement string can use regex matches to substitute part of the client spec name. If the value of this parameter has no spaces then it is taken as the name of a script to run. The script is run with the client and user names as arguments. If the script produces output then this is taken as the user name, otherwise the username is left unchanged. An example regex could be |
| Line 106: | Line 89: |
| which turns "firstname.lastname--my-client-name" into "Firstname Lastname <firstname.lastname@example.com>" | which turns "firstname.lastname--my-client-name" into "Firstname Lastname < firstname.lastname@example.com >" |
| Line 108: | Line 91: |
| The '''encoding''' option sets the character encoding used by p4. The '''P4CHARSET''' environment variable takes precedence, if it is set. | |
| Line 109: | Line 93: |
| If the '''ignorecase''' option is true then the Perfarce extension ignores all case differences in the p4 depot. Directory and filename case is preserved unless there is a collision. On collisions the name from the Mercurial repository is used. | |
| Line 110: | Line 95: |
| If the '''keep''' option is true (this is default) then the Perfarce extension will keep the p4 workarea updated with the current top of tree in p4. If '''keep''' is false then the Perfarce extension does not leave files in the p4 workarea unless it is creating a changelist. | |
| Line 111: | Line 97: |
| If the '''lowercasepaths''' option is true then the Perfarce extension forces all directory names received from p4 to lowercase, but leaving filenames unchanged. The default is to preserve directory and file names. The '''maxargs''' option sets the maximum number of command line arguments passed to p4. On windows the command line may be truncated silently by cmd.exe, and p4 also appears to truncate. The default (25 on windows, 250 otherwise) should be safe. If the '''submit''' option is true then Perfarce will automatically submit a changelist when pushing changes to the p4 depot. The default is to create a pending changelist, and let the user review this before submitting, either with p4 submit or hg p4submit. If the '''tags''' option is true (this is the default) then Perfarce will convert p4 labels into Mercurial tags. If '''tags''' is false then p4 labels are ignored. This can be used to reduce loading on the p4 server. The '''copy''' and '''move''' options record whether these operations are available on the p4 server. If these are not set then Perfarce will try to detect their availability by running p4 help copy, p4 help move as part of every hg push operation. Setting the variable skips the check. The '''pull_trim_log''' option can be used to remove the Mercurial node IDs from both p4 and the changes pulled into Mercurial. This option should be used with care, as it irreversibly changes the p4 depot and changes subsequent Mercurial clones. This generally is not desirable if the Mercurial repository has been shared. or if changes have been changed or modified with MQ, strip or similar. |
Perfarce Extension
This extension is not distributed with Mercurial.
Author: Frank Kingswood
Repository: http://hg.kingswood-consulting.co.uk/perfarce
Contents
1. Overview
This extension modifies the remote repository handling so that repository paths that resemble
- p4://p4server[:port]/clientname
cause operations on the named p4 client specification on the p4 server.
The client specification must already exist on the server before using this extension, and the working copy belonging to this client spec must be visible to hg as Root or one of the AltRoots in the client spec. If configuration keep=true then it is possible to share this working copy with local p4 operations. Note that the p4 and Mercurial workspaces should never overlap.
2. Commands
hg clone [--startrev REV] [-r REV] [p4://server/clientname]
If the source repository name starts with p4:// then this creates the destination repository and pulls all changes from the p4 depot into it. The --startrev and -r options set the first and last p4 changelist to pull. Setting a start revision causes the contents of all files at that changelist to be included in the first converted revision. There must be at least two revisions to clone if --startrev is set. After the clone is complete the Perfarce extension will write a .hg/hgrc file with the p4 address and the configuration options in use.
hg incoming [p4://server/clientname]
If the source repository name starts with p4:// then this reports changes in the p4 depot that are not yet in the local repository.
hg pull [-r REV] [p4://server/clientname]
If the source repository name starts with p4:// then this imports changes from the p4 depot, automatically creating merges of changelists submitted by hg push. The -r option sets the last p4 changelist to pull. If the perfarce.keep configuration is false then the import does not leave files in the p4 workarea, otherwise the p4 workarea will be updated with the new files.
hg outgoing [p4://server/clientname]
If the destination repository name starts with p4:// then this reports files affected by the revision(s) that are in the local repository but not in the p4 depot.
hg push [-r REV] [--submit] [p4://server/clientname]
If the destination repository name starts with p4:// then this exports changes from the local repository to the p4 depot. If no revision is specified then all changes since the last p4 changelist are pushed. In either case, all revisions to be pushed are folded into a single p4 changelist. Optionally the resulting changelist is submitted to the p4 server, controlled by the --submit option to push, or by the perfarce.submit configuration. If the perfarce.keep configuration is false then after a successful submit the files in the p4 workarea will be deleted.
hg p4id [-c CL] [-r REV] [-nip]
Shows the most recent or selected P4 changelist known to Mercurial, or the P4 changelist associated with Mercurial revision REV. The -n -i and -p options cause the local revision number, the global revision id and the p4 changelist number to be displayed.
hg p4pending [-s]
Shows pending changes, those that have been pushed and possibly submitted, but not yet pulled from p4. If the -s option is given, then the pending changelists are presented in a long format with summaries of the changelist comment.
hg p4submit [-a] [changelist]
Submit a changelist to p4. If the -a option is given then all changes that have been pushed will be submitted.
hg p4revert [-a] [changelist]
Delete a changelist from p4, reverting any file changes. If the -a option is given then all changes that have been pushed but not submitted will be reverted.
3. Configuration
Configure your .hgrc to enable the extension by adding following lines:
[extensions] perfarce = /path/to/perfarce.py [perfarce] keep = True submit = False tags = True lowercasepaths = False ignorecase = False clientuser = search_regex replacement_string encoding = ascii maxargs = 250 copy = False move = False
The clientuser option allows for 'cheap' multiuser operation with p4. The option argument is split on the first space into a search regular expression and a replacement string. If the regular expression matches the client spec name of an imported p4 changelist then the username for the changelist is changed to the value of the replacement string after it is capitalized. The replacement string can use regex matches to substitute part of the client spec name. If the value of this parameter has no spaces then it is taken as the name of a script to run. The script is run with the client and user names as arguments. If the script produces output then this is taken as the user name, otherwise the username is left unchanged. An example regex could be
clientuser = ([a-z]+)\.([a-z-]+)--[a-zA-Z0-9-_.]+ \1 \2 <\1.\2@example.com>
which turns "firstname.lastname--my-client-name" into "Firstname Lastname < firstname.lastname@example.com >"
The encoding option sets the character encoding used by p4. The P4CHARSET environment variable takes precedence, if it is set.
If the ignorecase option is true then the Perfarce extension ignores all case differences in the p4 depot. Directory and filename case is preserved unless there is a collision. On collisions the name from the Mercurial repository is used.
If the keep option is true (this is default) then the Perfarce extension will keep the p4 workarea updated with the current top of tree in p4. If keep is false then the Perfarce extension does not leave files in the p4 workarea unless it is creating a changelist.
If the lowercasepaths option is true then the Perfarce extension forces all directory names received from p4 to lowercase, but leaving filenames unchanged. The default is to preserve directory and file names.
The maxargs option sets the maximum number of command line arguments passed to p4. On windows the command line may be truncated silently by cmd.exe, and p4 also appears to truncate. The default (25 on windows, 250 otherwise) should be safe.
If the submit option is true then Perfarce will automatically submit a changelist when pushing changes to the p4 depot. The default is to create a pending changelist, and let the user review this before submitting, either with p4 submit or hg p4submit.
If the tags option is true (this is the default) then Perfarce will convert p4 labels into Mercurial tags. If tags is false then p4 labels are ignored. This can be used to reduce loading on the p4 server.
The copy and move options record whether these operations are available on the p4 server. If these are not set then Perfarce will try to detect their availability by running p4 help copy, p4 help move as part of every hg push operation. Setting the variable skips the check.
The pull_trim_log option can be used to remove the Mercurial node IDs from both p4 and the changes pulled into Mercurial. This option should be used with care, as it irreversibly changes the p4 depot and changes subsequent Mercurial clones. This generally is not desirable if the Mercurial repository has been shared. or if changes have been changed or modified with MQ, strip or similar.