David Jeske writes:

What you are describing is a very common concept that is referred to as a "checkpoint." If you are working on a personal/private branch for a single change-task, then you can checkin/checkout versions to & from the branch to your hearts content without having any effect upon the codeline you branched off from. All you would need to simulate checkpointing is a "checkpoint" wrapper that associates a checkpoint-label with all the versions that you just check-pointed.

If you are working directly on the codeline that is being used by others as the basis of the checkouts and branches, then a checkpoint feature would need to either:

a. retro-branching: retroactively "branch" your changes onto their own branch and _then_ checkpoint them.

b. private-tagged versions go ahead and checkpoint them where they stand, but using some additional feature that makes them appear "private", unseen by other workspaces (unless perhaps they *explicitly* ask to see what working versions are in your workspace). If you can't enforce the privacy automatically with wrappers or "smoke and mirrors" (perhaps using a label named "PRIVATE") then you may need to rely on some degree of convention and cooperation.

c. private versioning checkpoint them them into a private, workspace-specific repository that is separate from the depot. This is straightforward to "hack up" on your own with RCS or what have you, but its not necessarily much fun, and there are "gotchas" involved.

Another alternative is to use a floating label in place of a shared codeline branch. Then you can checkin/out all you want because client workspaces don't ask for the latest version on the codeline, they ask for whatever the "current" definition of the floating label is. When this "virtual codeline" (using the floating label) is ready to be updated, its owner performs the necessary integration and updates the label-definition to include the newly integrated versions. And if you *really* want, you don't have to branch a file unless it genuinely has _concurrent_ changes taking place.

Of course, this defeats some of the niceties that Perforce bend over backwards to give you when using branches, but it does have the benefit of not requiring any trivial copy-merges; unlike with a branch, the versions don't have to come to the label (pull), the label can come to the version (push). Whether or not you eventually merge all versions on the floating-label to a single branch is a low-level optimization or reorganization that you can perform at your own leisure.

Cheers!

--- Brad Appleton <bradapp at enteract.com> | http://www.enteract.com/~bradapp/ "And miles to go before I sleep." | 3700+ WWW links on CS & Sw-Eng