(Pardon the long side trip about our conversion, but I think it might be of interest, and I'm still pumped from it all!)

Network Appliance went "live" with Perforce as of last Monday 3/23. (Hurray). (This in the sense that we'd been using for some months on certain internal tools and web page sources, but not all all on main MetApp product sources until now).

Until 7PM last Friday, we were using CVS with a extra layer of front-end wrapperstuff called "cvslines". Disabled CVS checkins at 7PM Friday evening, and began a wholesale conversion of our entire product source base (and remaining internal tools that were still in CVS), including history, and branching structure.

The converter took about 26 hours to finish doing the longest-duration single chunk (I had other instances running on other hosts at the same time, but thay all finished up well before the big one). It's slow, because it does everything as discrete p4 client/server interactions, and we were, essentially, replaying about six years of CVS activity. (A *much* fast converter could be made with proper access to definitions of the db.* and journal formats, but Perforce doesn't want to make them an API (I don't blame them!), I didn't want to reverse engineer them, and, after all, this thing is only used once, really.

Anyway, the conversion finished late Saturday evening. There was a final step of merging all of the existing depot and converted chunks (using the perfmerge.pl script supplied by Perforce), and then, voila. By midnight Saturday, we were running a completely converted CM system.

But, being at least a little conservative, I spent most of Sunday checking the whole thing out, to verify that all of the required branches were intact and correct, "Header" -> "Id" conversions done properly, etc. By late Sunday evening, I couldn't see any reason not to, so I delcared it all open for business.

Nightly builds were kicked of as usual Monday at 2AM, and got their sources trees just fine from Perforce. (The build tools having been prepared in advance).

On Monday, engineers came in and started using the system. A handful had already been using it for internal tools, some had already trained themselves using on-line training materials (including an interactive tutorial) we'd put together, and some had avoided learning anything at all about Perforce to this point.

By the end of the day, we had somthing like 53 registered users, 150ish client workspaces, and (from the conversion) over 26000 submitted changelists (some 50 or so from that day, by new perforce users).

We use a perl wrapper (we call it "b4p4") that provides some valuable localizations, including shortcuts for setting up new client workspaces, and I think that helped some. (But knowing to tell users to do "p4 client -o <name> | p4 client -t <name>" would have also helped them a lot without the wrapper.

So far, I think we're all amazed at the smoothness of the whole transition. There's still al lot of work to do... bug tracking integration, more controlled change tracking in general... better merge tools to point $MERGE at; but so far, so good. And nobody has come after me with a noose yet! (To the contrary)

Anyway, you asked about the numbers.... sorry for the digression:

rmg $ p4 users | wc 58 311 3320 rmg $ p4 clients | wc 178 1386 14917 rmg $ p4 files //depot/... | wc 59421 356571 5041021 rmg $ p4 changes | wc 26128 297912 1991914 0 0 0 rmg $ p4 opened -a | wc 358 2864 41536

rmg (p4) $$ du -k -s root.p4netapp/db.* 4248 root.p4netapp/db.change 8 root.p4netapp/db.counters 8 root.p4netapp/db.depot 4292 root.p4netapp/db.desc 132 root.p4netapp/db.domain 8 root.p4netapp/db.fix 8 root.p4netapp/db.fixrev 154592 root.p4netapp/db.have <- expect this to grow fast 26124 root.p4netapp/db.integ 8 root.p4netapp/db.job 8 root.p4netapp/db.jobdesc 8 root.p4netapp/db.jobpend 212 root.p4netapp/db.locks 8 root.p4netapp/db.protect 40116 root.p4netapp/db.rev 19640 root.p4netapp/db.revcx 8 root.p4netapp/db.review 36 root.p4netapp/db.user 152 root.p4netapp/db.view 280 root.p4netapp/db.working

rmg (p4) $$ ll checkpoint.p4netapp/checkpoint.19980326061501 - -r--r--r-- 1 p4 89065796 Mar 26 06:21
checkpoint.p4netapp/checkpoint.19980326061501

The cron job fired at 6:15, so that's roughly six minutes and some for the checkpoint. I run 'em at 6:15AM 12:15PM 6:15PM and 12:15AM; I just told users to expect the server to take a short break at those times, and nobody's complained so far. I'll probably go to 1/day checkpoints before long, and I learn to trust everything more.

Right now we trust dialy filesystem dumps and NetApp server snapshots to cover us for $P4ROOT/depot/... backups, but I'll likley be doing something more about that soon.

All server restarts handled by init.d and a cron based watchdog; checkpoints by cron.

So far, I tend to do little "administration", though I am (as expected) spending a good deal of time teaching users how to use it, adding on to local tools and capabilities, etc.

(BTW, so far I haven't fiddled with protections at all. I'm not sure how valuable it is for us to be trying to restrict, via Perforce, who is permitted to see or modify various things).

- Richard Geiger