Perforce Configurations - Re: [p4] Anyone used StarTeam and have compare info?

Paul Andrei pandrei at
Thu Mar 17 09:03:20 PST 2005

In our current project, we struggled for a long time with the problem of 
how to create and use "configurations". A configuration would assemble a 
product from certain versions of various components. The components are 
developed independently, that is, they have their own codelines and 
branches in Perforce. Ideally, complete products would assemble 
everything they need under a monolithic tree.

What you are proposing Jeff is what I called 
"configuration-through-integration": you are really creating a 
configuration for each final product by integrating into their source 
trees certain *frozen* versions of the components they need. Note the 
highlight on frozen. This is usually sufficient, but not always.

I our case, we are refactoring a relatively complex set of related 
applications, which long time ago were forked from a common version. One 
task is to factor out the common components that we identify, while 
still managing the product releases for the complete applications. 
Configuration-through-integration (CTI) is not good enough because many 
developers need to work on the tip of each application and several 
components simultaneously. So we needed a configuration management 
scheme that can support multiple *unfrozen* components also. We wrote a 
configuration management tool on top of P4API. The configuration 
information is stored in XML files, which can themselves be versioned 
under Perforce.

But the ideal solution, and this a suggestion to Perforce, if they are 
monitoring this forum, is to implement some kind of symbolic links in 
the Perforce depots themselves.

Take this structure, for example:

|    //depot/Component1/main
|           /          /branchA
|           /          /branchB
|           /
|           /Component2/main
|           /          /branchC
|           /
|           /ProductX/Component1{//depot/Component1/main/... at label_001}
|                    /Component2{//depot/Component2/branchC/...}
|                    /Module1
|                    /Module2

The notation

     Component1{//depot/Component1/main/... at label_001}

denotes a Perforce depot symbolic link (PDSL) to a frozen version of 
Component1, while


denotes a PDSL to the tip of Component2 branchC.

Of course, all Perforce commands would need to be updated to follow 
these links when necessary.

   -Paul Andrei

jab wrote:
> I believe that the question on the table is "how to do development with 
> a body of components
> that came from various groups,"  not the specific question of "how to 
> have a directory appear
> in two places."
> The reason I reframe it that way is two-fold:
>     1. The higher-level question is more general, and more useful;    2. 
> The software engineering issues start to come up, if you have a common
>         component/directory that multiple projects might modify. The 
> issues are
>         that you might end up with a common subcomponent that needs to 
> be changed
>         for project B, but needs to remain frozen because project A is 
> in the middle of
>         a release cycle.
> One approach, that seems complicated on the surface but that might help 
> manage this,
> is to "integrate" the subcomponent directories into a "projectA/..." 
> tree and also into
> a "projectB/..." tree. You might end up with something that looks like 
> this:
>     //depot/componentdev/{cl,api,net,gui}/...
>         The places where the CL, API, NET, and GUI group does basic 
> development.
>         Note that each component has an "owner" of some sort, and no 
> component is
>         considered "ready for projects to use" until passing strong unit 
> testing.
>     //depot/projectAdev/...
>         The place that a Project A developer does work. He/she maps in 
> ONLY this
>         subtree, does a "p4 sync", and checks in/out files and plays.
> Now, how does Project A use the components? Read on...
>         //dept/projectAdev/cl/...
>             This was created by the Project A build-guy, using a command 
> such as
>             "p4 integ  //depot/componentdev/cl/... at cl_milestone1 
> //depot/projectA/cl/..."
>             It's a faithful copy of CL as of milestone 1.
>         //dept/projectAdev/api/...
>             This was created by the Project A build-guy, using a command 
> such as
>             "p4 integ  //depot/componentdev/api/... at api_milestone4 
> //depot/projectA/api/..."
>             It's a faithful copy of API as of milestone 4.
>         //dept/projectAdev/net/...
>             This was created by the Project A build-guy, using a command 
> such as
>             "p4 integ  //depot/componentdev/net/... at net_milestone2 
> //depot/projectA/net/..."
>             It's a faithful copy of NET as of milestone 2.
>         //dept/projectAdev/gui/...
>             This was created by the Project A build-guy, using a command 
> such as
>             "p4 integ  //depot/componentdev/gui/...@ gui_milestone2 
> //depot/projectA/gui/..."
>             It's a faithful copy of GUI as of milestone 8.
> We can do the same thing for Project B, but recording different milestones.
> This gives the projects a bit of independence from a lock-step set of 
> component
> releases, writes history records so that you can recreate the Project A 
> development
> environment to reflect any specific date/time, and you can update the 
> Project A tree
> to pull in a new version of the CL library when it's passed appropriate 
> unit testing.
> You can modify SLIGHTLY the copy of a component in your Project A tree, but
> it's far better to get to the owner of the component, have them issue a 
> new rev,
> and integrate down that new rev. That makes it cleaner for development 
> ownership needs.
> (Uhhh, you will pay attention to files that were in CL milestone 1 and 
> deleted in
> milestone 2, right? That requires a minor bit of special handling.)
> If the components are in DLLs and you cannot have two RUNTIME versions 
> of the
> same component on the same machine at the same time, this still gives 
> you a bit
> of room to stand on (in?) during development itself.
> Treat this as a software engineering question, not a software usage 
> question, and you
> might be able to craft something really helpful. Run it past 
> perforce-user or Perforce Tech Support
> before implementing, if you wanna get a basic sanity check on the thing 
> to make sure that it
> makes sense to others.
> And if you have component-level work, like this, insist that components 
> have owners
> who really do unit-test the stuff before announcing that the components 
> are ready to
> include in your Project A tree.
>     -Jeff Bowles
> ps. I've given slightly incomplete commands in this email. ("p4 
> integrate" requires
> a "p4 submit" and, perhaps in this situation, a "p4 resolve -at" also.) 
>  Be sure to practice
> this sort of thing on a test machine/server first, to get comfortable 
> with it.
> On Mar 17, 2005, at 5:58 AM, Bo Yang wrote:
>> Hi, John,
>> I am very interested that you can represent branches as directories in
>> the depot in your email. Could you share how that can be done?
>> I have some common library code in a same depot and I want those common
>> code be represented  as a directory in other projects without physically
>> located under those projects. Perforce is saying symbolic link is not
>> good.
>> Thanks in advance.
>> Bo
>> -----Original Message-----
>> From: perforce-user-bounces at
>> [mailto:perforce-user-bounces at] On Behalf Of John-Mason P.
>> Shackelford
>> Sent: Wednesday, March 16, 2005 3:49 PM
>> To: Shenon, Amanda
>> Cc: perforce-user at
>> Subject: Re: [p4] Anyone used StarTeam and have compare info?
>> Amanda,
>> We evaluated StarTeam and Perforce together (among others), selected
>> Perforce and have been using it very happily for about a year now. For
>> me a very clearcut reason we could not use StarTeam was that it did not
>> support a component development model where we could create a larger
>> project from various versions of individual components. With the
>> flexibility Perforce's workspace mapping combined with the
>> representation of branches as directories in the depot, Perforce handles
>> this easily. Borland showed us a custom tool they developed to try to
>> approximate this, but it was pretty shoddy. A few months after our eval
>> concluded I received an email from our sales rep. announcing that he was
>> moving to another company as he was concerned about the lack of energy
>> going into the StarTeam product. Like most vendors, the initial sales
>> pitch was good, but when it came down to brace tacks they just couldn't
>> perform. With these things the devil is in the details.
>> John-Mason Shackelford
>> Software Developer
>> Pearson Educational Measurement
>> 2510 North Dodge St.
>> Iowa City, IA 52245
>> ph. 319-354-9200x6214
>> john-mason.shackelford at
>> _______________________________________________
>> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
>> Learn more:
>> perforce-user mailing list  -  perforce-user at
>> _______________________________________________
>> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
>> Learn more:
>> perforce-user mailing list  -  perforce-user at
> _______________________________________________
> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
> Learn more:
> perforce-user mailing list  -  perforce-user at

More information about the perforce-user mailing list