13 messages in com.perforce.perforce-user[p4] Advice on multi-product depot or...| From | Sent On | Attachments |
|---|---|---|
| Jeffrey Jensen | 22 Mar 2002 11:14 | |
| Matthew Rice | 22 Mar 2002 11:39 | |
| wiv...@us.itmasters.com | 22 Mar 2002 12:30 | |
| Brian Moyers | 22 Mar 2002 13:17 | |
| Stephen Vance | 22 Mar 2002 20:34 | |
| Chuck Karish | 23 Mar 2002 00:34 | |
| Brian Moyers | 23 Mar 2002 12:58 | |
| Jeffrey Jensen | 25 Mar 2002 12:11 | |
| Jeffrey Jensen | 25 Mar 2002 12:12 | |
| Jeffrey Jensen | 25 Mar 2002 12:12 | |
| wiv...@us.itmasters.com | 25 Mar 2002 13:01 | |
| Jeffrey Jensen | 27 Mar 2002 08:54 | |
| wiv...@us.itmasters.com | 27 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,
-- matthew rice <matt at starnix.com> starnix inc. phone: 905-771-0017 x242 thornhill, ontario, canada http://www.starnix.com professional linux services & products
_______________________________________________ perforce-user mailing list - perforce-user at perforce.com http://maillist.perforce.com/mailman/listinfo/perforce-user




