Perforce Real-World Lab

Mark Lentczner, Glyphic Technology

Scenario 1

Dual Developement Groups

Big Corp. currently uses Perforce to manage their software. At present it is just a simple depot with no branches, just a mainline of coding effort. The software currently consists of about six hundred files spread out over eight directories. In addition, there are a number of other directories of files in the depot, some indirectly related and some unrelated to the software.

Things are about to get complicated at Big Corp. In two months they plan on releasing Version 1 of the software. Meanwhile, a sub-set of the engineers have been working on Version 2 of the software, using "#ifdef V2" throughout the code.

To complicate matters, the marketing department of Big Corp. has sold a very big customer a mythical version of the software that lies somewhere between V1 and B2, and includes some features specific to that customer. Engineering is, as usual, overworked, and so has hired Little Guy Consulting to create this version of the software.

Little Guy Consulting works in their own offices and also uses Perforce extensively. For reasons of security, convenience, and general comfort level, it is agreed that Little Guy will not have access to Big Corp's network. Little Guy will only have access to Big Corp's Perforce depot when they are visiting Big Corp.'s offices - which happens once or twice a month.

How should Big Corp.'s and Little Guy's depots be structured so that they can most effectively get their work done?

Scenario 2

Web Site Developers

Cool Gif creates web sites for the other companies. For most customers, Cool Gif provides a continued maintenance and content updates of the sites. Currently, Cool Gif's team of 30 designers and programmers are working on creating about 5 new sites, and maintaining about 30 others. About half of those sites are run on servers located at, and maintained by, Cool Gif. The other half are run at the customer sites.

Cool Gif's team members generally work on the projects on their own computuers (all Windows 95 or NT based), using personal servers and clients. There are a number of development servers (Linux or Solaris) that are used, mostly by the programming staff, for working on CGI programs that can't be developed on their own systems.

Cool Gif has a strict review process in place: Each project is reviewed in a group design meeeting each week. Because of the way designers work at a project design meeting, only those parts that are 'ready for review' are presented. A designer may work for two or more weeks on a part of a site before submitting it to review. Due to past problems with programmers from other projects crashing servers while reviews were going on, Cool Gif has a server that is used exclusively for reviews.

At the review meetings a determination is made if the work is ready for the client to review. At that point each week, the reveiw version of the site is made available to the client on a password protected server.

Cool Gif would like to move to using Perforce to manange their source. Further, it is felt that too much time is spent moving versions of web sites from developers' machines to the review machines, from the review machines to client review machine, and from there to the final servers. The current by-hand process is also error prone, to the occasional chagrin of Cool Gif when a client sees things they're not supposed to.

Lastly, the system administrators (two) have become intrigued with using Perforce to help with the final distribution of sites to the running servers. For servers that are at the clients' sites, they have investigated using ssh and installed it for test purposes at a few sites.

How should Cool Gif make use of Perforce to achieve its ends? How much of the distribution issues can be completely automated?

Scenario 3

Version Madness

Reckless Driver, Inc. creates software drivers for storage devices. They have three major software lines: Reckless HardDisk, Reckless CD-ROM, and Reckless Raid. Like most 'started in the garage' engineering firms, Reckless' software control system consists of copying source trees by hand, with a weekly archiving to diskette.

The base driver technology evolves over time, going through major release cycles about every one to two years. Unfortunately, the three drivers only directly share one piece of code: the Driver User Interface, or DUI, library. The CD-ROM and Raid software lines were made from copies of the HardDisk product source tree at a point in the past. When changes are made to the HardDisk product, they are remade to the other two.

For each client, Reckless produces a custom version of one or more of these drivers. For the portions of the code that they customize, there is significant coding involved. Because of this, and because each client receives the source, Reckless' engineers don't use '#if" constructs in code, but instead work in yet another copy of the tree for each customer.

From time to time, Reckless actually has a repeat customer who likes the drivers enough to want updated versions when Reckless has a new major release. The Sales department (one overworked person) thinks repeat business is great for the company. The engineers, understandably, hate it: bringing custom versions forward is a nightmare.

Given that you can't change Reckless' reckless coding practices overnight, how can a Perforce depot handle this morass of code versions?