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.

No comments: