Some suggestions (in the order in which our new users typically hit them): o A way to set up a default template that just "comes up" for users from the depot, so that they don't have to know more than "p4 client" to create their client, and/or can create it simply through the GUI. Ditto any other
commands that have template-based options. o When a submit fails, don't assign a change # to it, leave the change as the default change. o Occasionally, we have a submit fail due to client problems and leave the
,file.v, file on the depot; this makes further attempts to submit, once the client
problem has been sorted out, fail, until the ,file.v, file is removed from the
depot. It would be nice if the depot always made a point of removing those files when
returning an error to the client. We are hopeful we won't run into the problems
leading to this situation anymore, as they were typically due to the file being
added with a letter in a case in its path that didn't match the actual case of the
letter on the path to the file of the directories already in the depot. o Instructions on how to use the m command with a tool like vdiff32 to actually use the tool to merge the files. So far, I've been able to have vdiff32
show me its version of the merge, but not to save it in a way that has p4 use that
result as its resolution of the merge. o Ability to prevent a submit if any files (not opened) in the client are older than the depot. o A review of the errors messages and perhaps improvement/clarification on the actions that should be taken when various errors occur. o More descriptions in the manual as to the use of templates; I have the impression they might be useful, but haven't been able to figure out how to set them up for our use. [I am still reading the new manual, maybe it has more examples than the old one?]

Additional feature suggestions: o More robust off-line use; for example, have the p4 client puttable into
"off-line mode", where the user uses p4 commands to open, add, and delete files, and then a "p4 catchup" command to put the client back on-line and submit all the
off-line commands. o A built-in p4 unknown command; we rolled our own, but it's not complete, and
I've tried the perl script someone sent out, but it doesn't seem to like my
slash-confused, case-confused NT environment. o Able to move a change from one client to another. o Hooks into other IDEs, or a list of IDEs with which the SCC stuff is
compatible. We use both Mocrosoft's developer studio and Symantec Cafe/Visual Cafe. o Ability in the GUI to double click on a file listed on the client and have it
do its associated action (edit/open/whatever) like in Windows Explorer. o A similar GUI for Solaris. o Some menu-driven way to add a file to the client in the GUI, rather than drag-and-drop from Explorer. o Look into hooking into some bug-tracking products. o Ability to have templates for change descriptions in the submit and change commands, and recognition that if the description is completely empty or unchanged from the template, that the change should not be assigned a number, or the submit should not occur. o Ability to rename clients; this is different from the ability to move the
directory associated with the client -- I might want to rename my client from
ames_current to ames_bugs when I want to clarify what the client is for (perhaps because I
am creating another client named ames_feature). o A p4 command that does nothing but tell you which directory a given client
(default, the current client) is based in. Useful for scripting tools. Perhaps this
can be done with options on one of the current informational commands?

Seconding other peoples' suggestions: o More descriptions/examples of the use of branches. o Names for changes as an alternative to numbers. o Ability to unsubmit the most recent submit; or more generally, to unwind the depot back to a past given change number, with the changes ending up as open files in the client doing the unwinding. o Private submit. Useful for checkpointing a client at a stable point in
working on an uncomplete feature not yet ready for submitting. Something lighter weight
than branches. o More security -- harder to masquerade as an alternative user, tighter
controls on from which machines/user names/clients various commands are valid perhaps? o Query-before-performing mode on p4 submit and p4 revert (and maybe others?),
i.e. one last chance to back out. o provide p4 submit a list of files. o Making labels lockable o Ability to add text to a change description o Ability to merge&diff through the GUI, esp. with a GUI-based merge along the
lines of the MKS vdiff32.

Thanks! Ames. ames at cloudscape.com