On Thu, 20 Dec 2007 10:02:36 -0800, David Brown <[EMAIL PROTECTED]> wrote:
On Thu, Dec 20, 2007 at 02:05:24AM -0800, MattyJ wrote:
We've cut out the use of labels (at least from a CM perspective) and
solely use branch/changelist combos, pretty much for that reason.
That's really the only concrete, unchanging way to refer to a version
of a file in Perforce. Also, since the owner of a label can move it at
any time it's not 100% trustworthy.
Of course, label abuse is nothing compared to how client specs can be
abused in P4. I had to work on one project that had over 1,000 lines in
its client spec. The big problem is that the client spec isn't revision
controlled in any way. So, the CRM management people end up making a
copy
of a whole client spec to go with every version they label (so it would
actually be possible to get the state of the files in the old version).
Plus, I think they still don't trust it, since there is also a massive
network store that holds a complete expanded tree copy of every released
version. That's even less pleasant to use, since it has absolutely no
history.
Woah, hard to imagine a cilent spec that needs to get that nuts. I suspect
bigger problems are afoot.
But yeah, some folks think they'll be clever and make their own client
spec with all kinds of 'cool' stuff in it, then all of a sudden you have
five new branches you've never heard of.
By the way, in recent versions of Perfoce, you can (sorta) version client
specs. You have to create a 'spec' depot and it'll do it. It doesn't
really provide any functionality aside from tracking the text of the spec
definition (you can't point at an old version and say 'revert to this' or
'create new client based on ...', but at the very least you have access to
the definition and can cut and paste it into a new spec.
It would be nice if a spec depot kept track of which files were actually
in a label over time, but alas it just keeps track of the definition of
the label itself.
At the very least the spec depot is useful when someone accidentally
deletes their client and wants it back, or if you munge your triggers and
forgot to save a dump of it before you wrecked it.
-Matt
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
