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

Andreas Axelsson Andreas.Axelsson at dice.se
Fri Mar 18 00:13:16 PST 2005


Wouldn't the problem below be solved with an extra client spec for
ProductX?

I know there's no way to make a clientspec map to a specific revision of
a file or hierarchy, like @label_001 below suggests, and that's
something I too could wish for, but the actual mapping of components
from depot to ProductX in this case, would work just fine with a client
spec. If you got your team to use a script when syncing instead of
running p4 sync //... you could add the label part there.

Example client:
//depot/Component1/main/... //client/ProductX/Component1/...
//depot/Component2/branchC/... //client/ProductX/Component2/...

So what's really missing is a way to lock a clientspec to a given
revision, right?

cheers,
/axl

> 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
> 
>      Component2{//depot/Component2/branchC/...}
> 
> 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 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
> >>
> > 
> > _______________________________________________
> > 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