[p4] usefulness of a depot other than a top-level directory?

[Stephen Vance]

David --

Why do you say that doing integrations across depots can be a problem? 
That is not true in my experience or knowledge.

Steve

Weintraub, David wrote:
> The basic advantage you point out is that file names are shorter since
> you're using the depot as the top level directory instead of using the
> second level hierarchy as the top level directory:
>
> 	//SW/project/branch  vs. //depot/SW/project/branch
>
> The problem is that depot names are not exactly the same as directory
> names, and that can become a problem if you're not careful. You cannot
> rename a depot, and doing integration across depots can be a problem.
>
> Basically, unlike ClearCase, there is really no great advantage or
> disadvantage of using multiple depots. If you create dozens of depots
> and then decide that you made a mistake, you cannot easily fix it, but
> you can probably live with it. 
>
> -----Original Message-----
> From: Colfer, Brian [mailto:bcolfer at shopping.com] 
> Sent: Wednesday, June 07, 2006 1:34 PM
> To: Weintraub, David; Tim.Miller at reardencommerce.com;
> perforce-user at perforce.com
> Subject: RE: [p4] usefulness of a depot other than a top-level
> directory?
>
> I also come from the ClearCase world but I think the use of multiple
> depots can simplify processes at three levels:
> 1) It makes it easier to scope policies to particular areas.   I can
> more easily define a set of triggers to a particular depot,
> //third_party/... for example.
> 2) branch views that scope to particular projects can be simpler to
> understand:
> //SW/project/branch/... //ws_name/project/...
> //third_parth/product/... //ws_name/third_party/...
> (At least its easier for me to understand)
> 3) protections can be easier to organize
>
> I prefer to apply the rule that different depots represent different
> classes of policies to be applied to the artifacts.  This may be
> departmentally based or product type... Research and speculative
> projects that will not directly result in new products will have a
> different set of policies than are projects that are part of actively
> developed releases. 
>
>
> --Brian 
>
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Weintraub,
> David
> Sent: Wednesday, June 07, 2006 6:15 AM
> To: Tim.Miller at reardencommerce.com; perforce-user at perforce.com
> Subject: Re: [p4] usefulness of a depot other than a top-level
> directory?
>
> I'm from the ClearCase world where multiple repositories are the norm.
> In ClearCase, each depot has its own database for "metadata" (branch
> types, labels, attributes, etc). Under ClearCase, we tried to balance
> the faster and more efficient access of smaller depots to the
> maintenance headaches created by multiple depots. (If you have 5 depots,
> for a single product, and you want a single label on that product, you'd
> have to create five separate instances of that label -- once for each
> depot.)
>
> However, in Perforce, the entire server instance has a single database,
> so multiple depots doesn't improve user access. Depots cannot be
> (easily) renamed, and they make client specifications more complex since
> you've got to specify each depot independently. Nor, does it even matter
> to have multiple depots for such things as remote access.
>
> Depots can have a particular function on a Windows based system as a
> means of disk space allocation. Each depot can have its own directory
> for storage. For example, if I have two depots, they can be located on
> two different drives. However, this is not the case on Unix based
> systems.
>
> Unix has the ability to have symbolic links, so that if a disk drive is
> getting too full, a symbolic link can easily be created to point to
> another physical drive without the hassle of multiple depots. Plus, the
> Unix file system can also be setup to allow another physical disk to be
> mounted right in the Perforce depot without any problems.
>
> In the end, I'll go with Laura Wingerd in her book "Practical Perforce".
> She states that depots should be mapped to an organizational level. At
> extremely large companies, a depot maybe a business unit. This makes
> better sense than making a depot represent an individual product.
> Products may need to share code, so you have to figure out which depot
> does the shared code belong in. Products evolve, and mapping a single
> depot to a product can get messy. Mapping a product to a depot is simply
> too messy.
>
> On the other hand, business units are usually much more stable. Even
> when they get reorganized, their legacy can live on for quite a while.
> In smaller companies, a single depot maybe more than sufficient (not
> counting a possible spec depot, of course). In very large companies,
> there might be multiple depots, but even there, it's much more likely
> for them to have multiple Perforce servers (one for each major business
> unit) than having multiple business units share the same depot.
>
> -----Original Message-----
> From: perforce-user-bounces at perforce.com
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of
> Tim.Miller at reardencommerce.com
> Sent: Tuesday, June 06, 2006 10:27 PM
> To: perforce-user at perforce.com
> Subject: [p4] usefulness of a depot other than a top-level directory?
>
> Hi,
>
> By default p4d creates a depot called 'depot.'  You can create other
> depots (and delete the 'depot' depot).  But I'm not sure (other than the
> spec depot) what the benefits of a depot are or how to use them to
> advantage.  Or should I just think of them as a top-level directory.
>
> To keep pathnames short, I would like to create depots like this
> (below).  Is this a good idea?  A bad idea?  Pitfalls?
>
> Thanks,
> Tim
>
> //app1
> 	/main
> 	/branch	(full dev&sub-project branches)
> 	/rel
> //app2		
> 	/main
> 	/branch	
> 	/rel
> //user		(sparse task&defect branches, prototypes, non-production
> stuff)
> 	/jdoe
> 	/jsmith
> //mktg
> 	/fluff
>
> etc.
>
> --
> Tim Miller
> REARDEN commerce
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>