[p4] Anyone used StarTeam and have compare info?

jab jab at pobox.com
Thu Mar 17 06:37:03 PST 2005


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 perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of John-Mason P.
> Shackelford
> Sent: Wednesday, March 16, 2005 3:49 PM
> To: Shenon, Amanda
> Cc: perforce-user at perforce.com
> 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 pearson.com
> http://pearsonedmeasurement.com
> _______________________________________________
> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
> Learn more: http://www.perforce.com/conf
>
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
> _______________________________________________
> Come to the 2005 Perforce User Conference, April 14 & 15 in Las Vegas.
> Learn more: http://www.perforce.com/conf
>
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>




More information about the perforce-user mailing list