Created On:  20 October 2011

Problem:

How does StarTeam vault storage mechanism work for checkin and checkout?

Resolution:

Check-in
A new revision of a file is received by the storage system from a StarTeam client checkin
  • A hive location is chosen
  • The file is written to disk in a temporary folder in both uncompressed (original) format and compressed format
  • The uncompressed file’s MD5 value is computed
  • The compressed file’s size is compared to the uncompressed file’s size. If the size difference meets a minimum threshold, the compressed file is kept, otherwise the uncompressed file is kept.
  • The file chosen not to be kept is discarded
  • The MD5 signature of the uncompressed content is used for the file name
  • A file extension such as “.gz” is added to denote files that are compressed
  • The kept file is moved from the temporary folder into the appropriate folder tree subfolder
  • If a file already exists in the same subfolder with the same name (and therefore the same MD5), the new file is discarded since it is a duplicate

Check-Out
StarTeam client requests a file by providing its MD5 value
  • The storage manager locates the appropriate hive and subfolder and looks for both the compressed and uncompressed versions of the file
  • The file found is returned to the client with a parameter that indicates whether or not the file is compressed
  • If the file is compressed the client is responsible for decompressing it