13 messages in com.perforce.perforce-user[p4] Advice on multi-product depot or...
FromSent OnAttachments
Jeffrey Jensen22 Mar 2002 11:14 
Matthew Rice22 Mar 2002 11:39 
wiv...@us.itmasters.com22 Mar 2002 12:30 
Brian Moyers22 Mar 2002 13:17 
Stephen Vance22 Mar 2002 20:34 
Chuck Karish23 Mar 2002 00:34 
Brian Moyers23 Mar 2002 12:58 
Jeffrey Jensen25 Mar 2002 12:11 
Jeffrey Jensen25 Mar 2002 12:12 
Jeffrey Jensen25 Mar 2002 12:12 
wiv...@us.itmasters.com25 Mar 2002 13:01 
Jeffrey Jensen27 Mar 2002 08:54 
wiv...@us.itmasters.com27 Mar 2002 12:40 
Subject:[p4] Advice on multi-product depot organization
From:Jeffrey Jensen (JJEN@agribank.com)
Date:03/25/2002 12:12:46 PM
List:com.perforce.perforce-user

Thank you for your reply.

Yes, we could use separate Perforce servers for the different product areas. There are a few product areas that would have multiple products for shared code and labeling desires.

Thanks for the link to the MS presentation. They do mention multiple depots, but not multiple servers in it. I understand their use of multiple depots vs multiple servers, as it is one cohesive product made of subsystems. I would do the same.

So my inexperience-with-Perforce question relates to what to do with the unrelated products - do they need separate servers each or lumping all in one is fine-and-dandy? It's the metadata sharing I am currently hung up on. I am assuming the scalability will be there on one server, especially for our size.

I hesitate to begin the multiple-Perforce-server approach if it is not necessary.

"Brian Moyers" <bmoyers at bea.com> 03/22/02 03:17PM >>>

Matthew, could you let me know how you would split a single server into multiple depots? I know this can be done by simple syncing the code you're interested in, and then adding it into a new server - but what about the change history, integration history, etc?

Perforce has scripts available (but not supported) that allow you to merge the metadata from two depots into a single depot, but they don't have a way, from what I've heard from support, to split the depots and end up with something like you would have if you kept the depots separate in the first place.

My recommendation would be to use separate p4 servers (not just separate p4 depots within a single server) for the different product areas that don't share code. Depending on the type of product you have this may or may not be easy to lay out.

I'd recommend reading this power point presentation about Microsoft Windows NT development also: http://www.usenix.org/events/usenix-win2000/invitedtalks/lucovsky.ppt . The discussion there is about how they used a product called "SourceDepot", and how it saved the development of Windows 2000 - word has it that SourceDepot is really Perforce. They use a separate depot for each product area of NT development.

Lastly, I can say that with the installation of perforce we have here - over 500 users and 5 years of development history in one depot - I wish we had multiple servers for our product rather than a single server.

Hope that helps,

Brian Moyers Sr. Software Engineer, Infrastructure BEA Systems (415) 402-7416 bmoyers at bea.com

-----Original Message----- From: perf@perforce.com [mailto:perforce-user-admin at perforce.com]On Behalf Of Matthew Rice Sent: Friday, March 22, 2002 11:40 AM To: Jeffrey Jensen Cc: perforce-user at perforce.com Subject: Re: [p4] Advice on multi-product depot organization

"Jeffrey Jensen" <JJENSEN at agribank.com> writes:

1) Non-related teams looking at some extraneous-to-them entries in the depot

Appropriate use of 'p4 protect' (and 'p4 group' for convenience) and nobody will see anything that they don't need.

2) One big set of lists for all products, vs independent lists per product; e.g. changelist, branchspecs, labels

True. However, you can get change history for just one project with:

p4 changes //depot/productA/...

Branches and labels can follow a naming scheme so that each product is easily identified (eg. product1-version-1.0rc1).

One thing to keep in mind, it's easier to split a Perforce server into mulitple servers later on than it is to merge servers. If you find that one server isn't meeting your needs, split them then.

HTH,