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

[Weintraub, David]

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