Managing SourceServer Projects

By Christopher Prinos, THINK Technical Support, Symantec Corp.

With the introduction of SourceServer in version 6 of Think C / Symantec C++, developers have an integrated way of handling source code control from the Think environment. This is especially important in large projects where the large number of source files, and multiple programmers on the development team would normally make revision control a real challenge.

While SourceServer aids in the maintenance of such large projects, it won’t automate the management completely. There are some specific strategies that need to be used to be successful with larger projects. This article will present some of those techniques, and show you some tips for keeping projects manageable. Even if you use SourceServer for single person and/or smaller projects, many of the ideas can still be applied to improve performance and organization of SourceServer projects.

Version 6.0.1 Notes

There have been a significant number of changes and fixes to the SourceServer interface from version 6.0 to 6.0.1 of the environment. This article assumes you have 6.0.1. If you’re still working with version 6.0, you can get an update from Applelink, CompuServe, America On-line, or by calling Technical Support.

What is a Large Project?

For the purposes of discussion, large project means any project with too many files for a single SourceServer database. This depends on a lot of factors, including the speed of the Macintoshes you’re using, and whether or not you have the database located on the server. Even so, if you’ve worked with SourceServer you know that it’s not long before response becomes frustratingly slow. There is a way to prevent this however.

Since we’ll be talking about large projects, I’ll assume that they’ll be more than one programmer working on the source. Right off the bat, this means that someone will be accessing databases remotely. (Note: even when using servers, programmers need to access the databases with their own, local copies of SourceServer). Even if the hardware you have to work with is the latest and greatest, you won’t be able to load those 300-file TCL projects into a single database and expect it to work well.

OK, But How Many Files is Too Many?

As a guideline, you should limit the number of files per database to no more than 50 files. That’s a definite upper limit. A better limit would be 25-30. Although this requiems more work to set up the projects, the return on investment is good because of the time you and the other developers save in the long run.

One result of using more than one SourceServer project is that it requires some planning ahead of time. The precise setup of your multiple SourceServer projects is up to you, but I’ll present one way that can be effective, and is a logical extension to the way the files exist when they reside on disk (as opposed to stored in a SourceServer project).

I’ll be using an extended example of a project with several folders of source files. Since the Finder also gets bogged down with too many files in a folder, I generally don’t have more that 50 files per folder anyway. This sets up a painless mapping of folders on disk to SourceServer projects---each database represents the contents of one folder. Another way to do it might be according to the segmentation in you TPM project file, i.e., all the files from Segment 2 in one SourceServer project, files from Segment 3 in another, and so on.

No matter which way you do it, the end result is that you end up with lots of little SourceServer projects. To make things complete, you’ll want to nest them so that you have access to all projects without individually mounting/dismounting them.

Setting up Nested SourceServer Projects

Creating a set of nested projects is not any different from creating a normal project. In the example that we’ll be looking at, the top level of the nested SourceServer projects will be called “Dino Sources DB”. This project will contain main.cp and its header file. The Dino Sources DB folder will contain a projectorDB file after the project is created, as do all new SourceServer projects. Later, we’ll put other SourceServer projects inside the Dino Sources DB folder as well.

After creating the top level SourceServer project, a new SourceServer project will be created for each sub project. In my example, I have four folders with source and header files, so I’m going to use a total of four SourceServer databases to keep track of them. The picture below shows the file setup after all the databases have been created, but before the nesting has been performed. The folder “Dino++” has the Think Project Manager file and two source files in it. It’s database will be “Dino Sources DB”. Under the “Dino Sources” folder, there are three more sub folders. “Core Headers” contains a little over 40 files, as does “Core Sources”. Each of these will have their own SourceServer database. The folder “Other” has both source and header files, but only about 18 total, so they will go all in one database.

The following picture shows the results of making the SourceServer databases into a nested hierarchy. There’s no magic here...the folders were just moved in the finder. Note the correspondence between source folders and their database folders. Note also that I’ve nested the “Core Headers DB” project under “Core Sources DB”. That doesn’t quite match the folder setup of the actual source and header files. In reality, this doesn’t much matter. As you’ll see in the Check In/Out dialogs later, all nested projects are listed in a single popup anyway. The only thing that nesting does is insure that all sub projects are mounted at the same time. So, in our current configuration, mounting “Dino Source DB” mounts all the projects. If we instead mount “Core Sources DB”, we will only get “Core Headers DB” along with it, and not “Others DB”.

By the way, this is the real reason for nesting the header file database inside the “Core Sources DB” folder. If we are interested in looking at the Core sources, chances are good we’ll want access to the header files also.

Once the databases are properly configured, it’s time to go through Check In. For some projects, files are introduced incrementally as the project develops. Here, we are assuming most of the files exist to begin with. Before starting the checking, make sure that the TPM project file is up to date (all files compiled). If it’s not, then some of the source or header files may not show up in the Check In dialog. Doing a mass Check In of files into nested databases is a little more time consuming than using a single database, because you’ll have to pick and choose your files for each sub database. Notice in the picture below, only the Core_xx.cp files have been selected, and that the “Project:” popup menu at the upper left is indicating “Core Sources DB” as the current project. Be sure that the current project is correct when you do the Check In.

After the Check In, the customary write-lock icons will appear next to the Checked In files (assuming the default Check In, which keeps a read-only version of the file)

You will want to continue the Check In process for all other types of files, and their respective databases, again keeping in mind that the current project must be correct for each phase of the Check In. The Check In dialog below shows the setup after we have checked in all the ‘Other” files into Other DB. Note that it contains both source and header files, since we had determined that the total number of files was small enough to keep from using separate databases.

Making Use of Named Revisions

When working with a large number of source files, the Check In/Out process can become a lengthy one if you need to pick and choose a subset of particular files or revisions. Using the Named Revisions feature, you can let SourceServer do some of that work for you. The basic idea is that you can defined a named set which always refers to the same files. The sets may be defined on a static (locked revision number) or dynamic (most current version) basis. To create a Named Revision, first choose the “Name Revisions...” command from the SourceServer menu. A dialog like the one below will appear. At the top is a popup menu showing the database that you are viewing. The top scroll lists shows files from that database, and the bottom scroll list shows what files you have chosen from the database to appear in a named set. You can move files from the top list to the bottom using the “All”, “Sources”, “Headers”, and “Add” buttons. Likewise, you can remove files from the bottom list with the “Remove” button. The popup menu which says “Named Set” is left at that setting when you are creating a new set of revisions. If you click on it, you’ll see a list of all the Named Revisions that you have created, allowing you to modify the contents of any particular revision. In the example below, all the source files from “Other DB” have been selected to form a static set named “Other .cp (B2)”. The “Rev:” popup’s other choice is for dynamic revisions. Use of the static in this way allows you to define a particular set of files. In this case, all the Beta-2 copies of Other_xx.cp. This named set will always refer to those versions of the files, regardless of the most recent versions.

The next example shows the creation of a dynamic set, which will probably be used more often. In the Name Revisions dialog below, I’m defining a dynamic set called “other.h” to refer to all the header files from the “Others DB”. Since this named set is dynamic, it will always refer to the most current versions of each of these header files. Dynamic sets are what you want to use to define you’re working set of source files.

There is a limitation to the Name Revisions command that applies in particular to those using nested sub projects. You cannot define a single named set which has files from more that one SourceServer database, even if those data bases are nested. This is important to know, since the dialog will allow you to set up just such a revision. In the Name Revisions dialog below, the currently selected data base is “Dino Sources DB”, but I have files in the set from each of the other databases.

Although this seems like a perfectly natural thing to do, SourceServer won’t go for it. If you go ahead, you’ll get an error message similar to the one below. Note that it didn’t flag the file “main.cp” as having a problem. That’s because main.cp was part of the database selected (Dino Sources DB) when the dialog was dismissed.

If you need to have working set that spans sub projects, the only way to do it is to manually define a similar set of names for each sub project. That is, you might have named sets that look like “Core .h B1”, “Core .cp B1”, “Other B1”, etc.

Once a named set is defined, you can use it to replace manual selection in the Check Out dialog. The example below shows a Check Out of the current Other_xx.h files using the “other .h” set. If a static set was being checked out instead, then the version number of each selected file would appear. For example, instead of “Other_1.h” being selected, it might show up as “Other_1.h,2b2”.

Check Out Directories

In the checkout dialog, there is a “Checkout To:” popup menu which allows you to define which directory files will be placed in once checked out. Normally, you’ll leave this at “Default Directories” as shown in the last dialog. When “Default Directories” is chose, files are checked out to where last resided on your disk, according to the TPM project file. Note that the locations of any file in a TPM project (.c, .cp, .r, etc.) have their locations stored by the TPM project. This is in contrast, however, to the way header files are located. When you check out any .h file using “Default Directories”, a search will be done to find a local copy of that file in your TPM or the Think project tree. If the file is found, it’s replaced by the one SourceServer retrieves from the database.

As an example, let’s say that I wanted to modify the file “Other_1.h”. I would go through the normal Check Out process. I have a local copy of this file in “:Dino Sources:Other:”, so that’s what gets replaced.

It is possible, however, that I don’t have a local copy of the file. This would be the case if it was checked in with the “Delete my copy” option, or if someone else created the file, and this was the first time checking it out. In either case “Default Directories” won’t be able to find a local copy of “Other_1.h”. Instead it will put up an error alert similar to the one below:

As the alert notes, you still get the file you want, but it appears in your TPM project directory--not necessarily the location it belongs. The finder snapshot below shows the result of checking out “Other_1.h” when no local copy existed. Once the file is checked out, you can go ahead and move it to the “Other” folder without consequences as far as the way SourceServer or your TPM project uses the file.

You can avoid having to move header files around like this by always keeping a local copy of the header files that you work with. They will serve as place holders for the Check Out command. Alternately, if you keep all the headers in a single directory, you can set that directory in the Check Out dialog, alleviating the need to keep local copies of the headers as place holders.

Using Newer During Check Out

Most of the time, the majority of files that you are working on are read-only copies that you need to make your builds. As you make changes to the set of files that you have checked out as modifiable, others will be making changes to other files. The “Newer” button in the Check Out dialog gives you an easy way to update all the read-only copies. You do this by option-clicking on the “Newer” button. This will select all files that you have local copies of, if you don’t have the current version. It will not overwrite files you have checked out as modifiable.

If you just click (instead of option-click), the “Newer” button will select only those files that you don’t have local copies of. If you keep place holders for all your files, nothing will be selected by the “Newer” button

Mastering the Command Line

If you’ve used Projector under MPW, then the SourceServer command line will be very familiar to you. In fact, it’s exactly the same with a few exceptions. Version 6.0.1 contains a SourceServer ReadMe file that details the command line commands and options, so I won’t go into them here, but I will touch upon some of the more useful commands that cannot otherwise be used from the TPM.

One of the most useful command-line entries is the ProjectInfo command. ProjectInfo lets you retrieve information about what and when files were checked in/out, along with who was responsible, and all the comments that were made. You can get that information on a project-wide basis, or narrow it down to certain files or date ranges.

As with all command line entries, you issue the ProjectInfo command by typing ProjectInfo followed by <control><enter>. Generally you’ll do this in an untitled window. The example below shows a simple query that retrieves some of the information on files from the “Others DB” project.

All of the discussion so far has been with files that we want under source control, but sometimes there are files that we want to remove as well. There’s no way to do this from the SourceServer menu, but you can use the OrphanFiles command to remove all SourceServer information from a file. It works by removing the ‘CKID’ resource from a file, thus removing all association with a project. Note that once you do this, you will not be able to check that file back into the revision tree from which it came. If you want to check it back in, it has to be done as a new entry.

If you want to remove files from a database entirely, you can use the DeleteRevisions command. There are two ways to use this command. One is to remove an entire revision tree:

 DeleteRevisions  -y -file Core_3.cp 

or you can use it to delete old versions that you no longer need:

 DeleteRevisions -y Core_3.cp,8

deletes all revisions up to 8. Note that you can’t pick and choose which revisions to delete ( 3 to 6, for example), you can only do it by specifying all revisions up to a certain number. One last note on DeleteRevisions... you should always use the -y option. This dismisses a confirmation dialog that you would otherwise not be able to access.