[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