Disclaimer

The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, August 21, 2014

Perforce Anti-Patterns --- labels

Perforce Anti-Patterns | Perforce:



'via Blog this'



While I agree with encouraging use of things other than labels (changesets, automatic labels, brancghes can all be equivalent for labels)



I think that calling this an anti-pattern is specious.



There are anti-patterns that are fundamentally bad.



But there are also anti-patterns that are bad just because of a poor implementation - and apparently Perforce's implementation of labels is poor.



Conceptually, a changeset is very much like a label - a set of files and versions, with comment metadata.  (Again, using the "files at the bottom" mindset, which I don't like, but which I find easier to think about.)



Similarly, a branch is very much like a label - or, rather, the place on a parent where a branch starts.



These are similar conceptually, and probably should be interconvertible.



It is foolish to create a rather heavyweight concept like a branch, a contour, will do.



Perforce;'s slowness probably arises because it has a table that looks like



filename : version : branch-name



which grows as #Files*#Labels.



Even worse if the metadata is stored RCS like, replicated per-file.  I can't imagine Perforce being that silly ... now ... although I suspect they may have been historically.