c4 - CVSish wrapper for perforce p4 program
c4 help c4 client-create -t <template> <client> c4 client-delete -d -f <client> c4 [-n] update c4 unknown c4 <any p4 command> i.e.: c4 add <file> c4 delete <file> c4 diff <file>
C4 allows a default user, see the ENVIRONMENT section.
When passed a filename on any c4 command, c4 makes the filename absolute, with all symlinks reduced, and chdir's if possible to the first such filename. If the argument is a directory, a /... is appended. This makes it a lot more likely that perforce commands will work when issued from outside a client area. (For example: c4 add /my/area/boo/blaz.) For this to work best, your p4 ClientRoot should point to the area that is physically on the disk, with all symlinks resolved.
When a client is created in a special way, C4 makes p4 seem more like cvs by having all files writable by default. C4 adds several commands (update/client_create) to support this, see the COMMANDS section.
Any command not listed here is passed directly to perforce.
Return the maximum change number present in the current client or passed list of files.
Create a client specification, making sure it gets named, and setting the clobber, allwrite, and rmdir attributes as required for c4 update. Also, create a .p4config file with the name of the client in it.
Delete a client specification in a way which leaves the database as clean as possible. Consists of the following steps:
p4 revert ...to make sure no files are left open.
p4 clientto edit the spec to remove any View: lines.
p4 syncto remove the views that were deleted from the file system.
p4 client -dto remove the client spec.
rm .p4configto cleanup the local directory.
This performs a p4 submit.
Under c4 style management, it prints an error if the area is not up to date before submitting. -f overrides this check. Use -f carefully as edited files may not yet be opened for editing as they would be if the update was done.
Under traditional management, or with the -p4 flag, calls the normal p4 submit command.
This performs a p4 sync.
Under c4 style management,
c4 update should be used instead. Under traditional management, or with the -p4 flag, calls the normal
p4 sync command.
Update is similar to cvs update. With -n, only the actions to be taken are shown, it does not actually change anything. On an update without a -n, c4 performs the following steps:
p4 editany files that have been changed from the version checked out from the depot.
With the -a option,
p4 addany files that are unknown to perforce (? becomes an A.)
With the -rl option,
p4 deleteany files that are missing in client (l becomes an R.)
p4 revertany files that were
p4 edited, but now match the version in the depot.
p4 syncto get recent changes.
Look for any unknown files not in a .cvsignore file.
A "c4 update -a -rl" will thus issue appropriate adds and deletes to make the depot match the current client view.
Update also prints a summary of each file that is modified in the client area, and with the -pi option, ignored (i) files are listed as well. Lowercase letters are used for actions that were not caused by the user, and are different from cvs letters. Here are the letters, the state causing that message, and what may happen on an update.
A (A)dded in client, not yet in depot, stays Add. M (M)odified in client, different from depot, stays Modified. R (R)emoved in client, still in depot, stays Removed. U (U)pdate required, unmodified in client, new version from depot. a Never in client, (a)dded in depot, will appear. d Same in client, (d)eleted in depot, will disappear. l (L)ost in client, exists in depot, will appear. m (m)odified in client, but now matches depot, will be reverted. i (i)gnored and not in depot, and in .cvsignore or global ignores. ? Unknown - Not in depot, not added, not in .cvsignore, no action.
Unknown files (?) should be ignored with a .cvsignore file as described in the FILES section.
Prints files that are not known to perforce, and do not have a .cvsignore line. This is similar to the '?' lines printed by "c4 update -n", however "c4 unknown" may be used with standard perforce clients.
With -a, mark all unknown files to be added to the depot (same as -a option in c4 update.)
Displays this message and program version and exits.
If specified, when a command is issued and the USER does not have a P4 license, then rather then create a new P4 user, the user in C4USER_DEFAULT will be used. This allows infrequent read-only users to share the same license.
If specified, adds space seperated list of ignores to global ignore list. See .cvsignore below.
This is a temporary file created and maintained by c4 in the top level of your client area. You may safely delete it, however the next c4 operation may be significantly slower.
Specifies files that are in the same directory as the .cvsignore that should be ignored; there will be no ?'s printed when a 'c4 update' is executed.
Ignore files are mostly compatible with CVS. The list of global ignores is initialized with:
*~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln .c4cache .p4config .make.state .nse_depinfo .dependency-info tags TAGS core
Patterns in the home directory file ~/.cvsignore, or the CVSIGNORE environment variable are appended to this list.
Each directory may have a local '.cvsignore' file. The patterns found in local `.cvsignore' are only valid for the directory that contains them, not for any sub-directories.
In any of the places listed above, a single exclamation mark (`!') clears the ignore list. This can be used if you want to store any file which normally is ignored.
The wildcards * and ? are honored, no other wildcards are currently supported.
As with CVS, comments are NOT supported!
The latest version is available from CPAN and from http://www.veripool.com/.
Copyright 2002-2005 by Wilson Snyder. This package is free software; you can redistribute it and/or modify it under the terms of either the GNU Lesser General Public License or the Perl Artistic License.
Wilson Snyder <email@example.com>