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

[Weintraub, David]

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