Rob, et. al.,

It's not a perforce vs. the_rest_of_the_archaic_world mindset. It's a difference in job function. IMHO, perforce is likely not to be adopted into the largest installations (perhaps by Chris' design) until or unless more flexible reporting of meta data is provided. Again, is likely by design, since flexibility is frequently inversely proportional to performance.

Having said that, again, I reiterate *ONE* use of dates which *IS* useful to project program managers. When monitoring a project as a milestone date approaches one wants to keep your eyes on several important metrics including bug open rates, bug close rates, files changes, lines changed, how quickly builds are being turned around, how many failed builds there are, etc. Generally, you want all these numbers getting smaller, converging to zero, as you approach Alpha, Beta, FCS, etc. No doubt it is not difficult to get at this data moving forward day by day. It gets harder when you want to go back and, perhaps in the midst of a post mortem, figure out what happened 3 weeks ago that caused all that thrashing.

As for the creation of software, components of builds, in theory and in practice, changes consisting of files is the way to go. It's clean, it's consistent, it's logical, and it's deterministic. In short, it appeals to me on many levels.

Maybe we need some The Zen of Perforce SCM white papers. ;)

Peter ===================== Peter DiPrete Consultant, ITE Corp pdiprete at auspex.com Office: (408)566-2432 Cellular: (408)221-1601 Pager (numeric): (888)533-3727, PIN# 4082211601 Pager (text): 4082211601 at paging.cellone-sf.com