it seems to me that keeping the "branch" object in Perforce may not be entirely necessary after an integration has been submitted.
I.e. the "real" branch, is actually a folder path, and even if you delete the branch object that was created to perform the integ, the folder path is still valid, and all the files in this path are still there (with versionning restarted from #1, etc...).
What puzzled me is that when I try to edit a branch (object) name, it instead creates a new branch which is the copy of the previous one with a new name. But if I delete the previous one, no harm seems to have been done (at first glance).
Is a branch object in Perforce in reality just a convenient mechanism for the tool that can be destroyed and recreated at will, as long as the mapping it describes is kept identical ?
Thomas
Version Control + Branching Branching is what allows developers to make those changes without impacting other users. Then their changes can be merged back into the codebase.
Description. Using the client workspace as a staging area, the p4 copy command propagates an exact copy of the source files to the specified target by branching, replacing, or deleting files. No manual resolve is required. Changes in the target that were not previously merged into the source are overwritten.
The p4 client command puts the client spec into a temporary file and invokes the editor configured by the environment variable P4EDITOR . For new workspaces, the client name defaults to the P4CLIENT environment variable, if set, or to the current host name. Saving the file creates or modifies the client spec.
By "branch object", I assume you mean "branch specification"? Branch specifications are what you create on the tab labeled "Branches" in P4V. Yes, these are just a convenience and in no way effect the actual branched files. You can delete them and the actual branch they describe will not be touched.
A branch specification is not necessary to perform branching and integration operations. That can all be performed via the Integrate... item that is available on the context menu of files and folders in the Depot Tree. The branch specifications allows you to do that more easily by setting up mappings between trunk and branch. We typically don't use them because our branch specs would typically consist of something like this:
//depot/foo/dev/... //depot/foo/v1.5/...
Creating a branch spec for something this simple doesn't really save us any time. It's when the mapping between the trunk files and the branch gets more complicated that branch specifications prove to be useful.
Branch specifications are entirely separate from actual branch/integration operations, however branch specifications allow more complicated integrations than are easy to do with straight paths. (e.g. gathering multiple paths together, or re-arranging a tree).
I'm not sure if there's anything that couldn't be expressed as a sequence of integrations of filepaths?
The advantage of keeping a complicated branch specification around is that it makes it easier to perform incremental integrations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With