views:

322

answers:

2

Hi,

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

+7  A: 

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.

raven
Yes, that's what I meant. Thanks for your clear answer. :)Thomas
Thomas Corriol
+1  A: 

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.

Douglas Leeder