The Native-II vault improves StarTeam performance (as compared to the old vault structure referred to as Native-I) and allows you to store much larger files than in earlier releases of StarTeam. Additionally, server configurations using Native-II archive files enable you to perform backups without shutting down the server. StarTeam server configurations support Native-II vaults only.
The sections below explain how StarTeam handles add, check-in, and check-out operations.
To add a file to the Native-II vault, StarTeam Server stores the revision in a temporary folder, computes the MD5 value of its contents, and checks how well it compresses. If the compression is 10% or greater, the Server moves the compressed version to the archive for the hive and its uncompressed version to the cache for the hive. If the revision does not compress well, the Server moves the uncompressed version to the archive for the hive.
StarTeam converts the MD5 value to a hex string and uses it as the name for the archive file. StarTeam uses the .gz extension when it compresses the file archive. If an archive file already exists with that name, StarTeam does not create a new archive file—although the StarTeam properties for that file are set to identify the hive in which the revision is stored, the use of compression, and the name of the archive file.
To check in a file revision to a Native-II vault, StarTeam Server stores the revision in a temporary folder in the next hive in the hive rotation. Then the server computes the MD5 value of its contents. If an archive file with the correct name already exists in the hive, StarTeam does not create a new archive file, although StarTeam updates the revision properties for the file. Otherwise, StarTeam creates a new file archive. Notice that no two files that are identical in content are ever stored in a given hive.
If the StarTeam file was initially identified as one that compresses well, StarTeam compresses the file revision and places it in the hive’s archive with a .gz extension. Its uncompressed version is moved to the hive’s cache. Otherwise, the uncompressed version is moved to the hive’s archive.
To check out a file revision from a Native-II vault, StarTeam Server checks the hive ID of the revision and archive filename. Then the server retrieves the file revision from the specified hive’s cache or archive, and it sends the archive file directly. These clients know how to decompress the archive file when necessary.
Every archive path and cache path for a hive has the same structure. This structure is similar to that used by StarTeam clients to store file status records.
StarTeam organizes the files located in the Archives and Cache folders into subfolders. This makes browsing and managing the files easier. The name of the subfolders in which StarTeam stores a file revision is based on the initial characters in the name of the archive.
For example, suppose the contents of a file revision has an MD5 value of 01fc3c4ac5e0e92cc707f30fb73a0726. Assuming the user specified an Archives path of C:\DefaultHive\Archives, the Archives path for this revision would be one of the following, depending on whether or not StarTeam compresses the archive file:
C:\DefaultHive\Archives\01\f\01fc3c4ac5e0e92cc707f30fb73a0726
C:\DefaultHive\Archives\01\f\01fc3c4ac5e0e92cc707f30fb73a0726.gz
StarTeam uses deltas to optimize for slow connections. To use this feature, users set the personal option named Optimize for slow connections found in the client on the File tab of the Personal Options dialog. Then when a user checks out a new revision of a file that is already in his or her working folder, the server recognizes the revision number for the working file and sends only the difference between that revision and the revision that is being checked out.
StarTeam Server stores each delta for later use in the Deltas folder, a subfolder of the Cache folder found in each hive. The file containing the delta is given a name that combines the names of the two archive files used to generate the data. For example, if the file revision for the client on disk has an MD5 value of:
7f46c2bb9602fe972d952f4988ab85cd
and the requested revision has an MD5 value of:
7f46c2bb9602fe972d952f4982ab35aa
then the server generates a delta between these two revisions and names it:
7f46c2bb9602fe972d952f4988ab85cd.7f46c2bb9602fe972d952f4982ab35aa