[p4] yet again

Tetlow, Gordon gtetlow at soe.sony.com
Tue May 8 13:17:29 PDT 2007


> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of 
> Steve M. Robbins
> Sent: Tuesday, May 08, 2007 11:52 AM
> To: perforce-user at perforce.com
> Subject: [p4] yet again
> 
> [This is my third try at sending.  Apologies if you have
> seen this twice already.]
> 
> On Thu, May 03, 2007 at 12:01:49PM -0700, Jeff A. Bowles wrote:
> 
> > I would use the newer label spec feature, so that you could say
> > "the label project1_build96_Mar15 is //depot/main/... up to change
> > 12381". It's a small amount of programming (the "Revision:" field
> > and the "View:" section of the label spec - perhaps 10-12 lines of
> > Unix shell script at most) and has very low database 
> storage overhead
> > compared to using "p4 labelsync" for this situation.
> 
> I wonder if you could expand on this a bit.  
> 
> For example, what are you referring to by "newer label spec feature"?
> On our 2006.1 server, at least, "Revision:" doesn't appear in the
> label spec, so I assume you must be speaking of a newer p4.
> 
> I'm mainly curious about the comment regarding database overhead for a
> label.  I'm new to p4 and naively a label seems like the right tool to
> identify released code versions.  However, my boss -- who has
> previously used p4 -- is allergic to labels and I think part of the
> reason has to do with DB storage.  Is a label a lot of overhead?  I
> imagine that a label is basically the same size as a changelist as
> conceptually both have to store pairs of (filename,revision).

Labels have massive overhead in the database. Basically, every file in
the label has to have an entry in the database.

-gordon



More information about the perforce-user mailing list