Files Storage mechanism

This document is proposed to explain the basic concepts of change's storage for different files types.

We have the following possibility to store files changes:

• Storage full revision.
• Storage only files delta.
• Others case - delta only.

Binary files - Executables, DLL, BMP, Form Word Document etc - all files where small changes in file may change all files contents. For example - small changes in source code may proceed big changes in "exe" file, small changes in pictures may change all bmp file.

Text files - it is simply txt files, c, cpp, html and others types of "plain" files. Simplest way to understand type of file, if you don't know - try to open it with Notepad - if it is work - it is plain file.

Only for plain files question of reverse or forward delta is relevant, for binary files always should be chosen options - "Store full revision".

1. Reverse delta

It is basic mechanism for CM tools. We have only last revision of file and possibility to rebuild old revision. If you want to receive revision with number (current -X) CM should proceed X operation. If, for example, now we have revision number 30 and you want to receive revision number 27 CM has to do 3 operation, but if you want to return to revision number 4 - CM should do 26 operations. It is very important to understand, that CM tool in this case operate step by step - it should rebuild revision number 29, afterwards number 28 etc. If you want to delete revision, CM should rebuild revision before deleted and include in it all changes from deleted revision.

For part of CM Tools deltas are stored in file system - PVCS,MKS etc, for others in database - Continuus, Visual Source Safe. But common in this case that these deltas "per file" - all changes of file stored together.

2. Forward Delta

First revision is stored "as is" and for each new revision deltas are stored.

Usually last revision also stored "as is" for fast access to date. If we work with revision number 30, like previous case, and you want to receive revision number 27 - it is 27 operation. In this case also operation should by done step by step - CM should start from revision number 1, to build second, etc. If you want to return to very old revision - for example to revision number 3 - it is only 3 operation.

In case of forward delta changes also "per file", and it is not so important, where are stored - in file system or in database.

3. Cache mechanism.

In two cases (forward\reverse delta) the main minus is the speed of operation. For improvement of operation many products have virtual cache operation. In special place (usually in file system) a few last version of the product are placed. During check in \ check out operation CM proceeds simply "copy" operation to "cache" and only afterwards - check in \ check out to archives.

Starteam use this mechanism for forward delta (15 revision) and VSS for right delta (2 revisions).

Starteam cache mechanism - last 15 revisions are stored in special place in file system - subdirectory "Cache" under server directory. In this place 15 last revision are stored "as is". If you want to receive one from last 15 revision Starteam simply copy files from this directory without rebuilding revision step by step from first revision. It is very fast. But if you want to receive one of revision, which is not placed in the Cache, this operation may work a few minutes.

In the case of VSS no special "cache" directory and two last versions are stored together with archives with special extension ("a" and "b").

4. Others - Delta only.

TrueChange has special mechanism of information storing. In this product we have not revision of files and question about "forward or reverse delta" is not relevant.

For each bug\problem\enhancement CM create "ChangeSet" which include information about all changes in all files which were changed during bug repairing. For example you want to do changes in your product and you did check out for 10 files. You changed 8 files and did checkin. Very important understand, that operation check out and checkin not "per file", but "per problem". You can start from checkout for 5 files, and afterwards to add 5 files, but all files now is linked to same ChangeSet. Checkin operates not "per file", but "per changeset". If you changed only 8 files from 10 in ChangeSet information will be written only about 8 files.

All information about changes in all files which are linked to bug\enhancement repairing is placed together - it is main difference from other products.

If afterwards you want to return to previous version of your product you cannot choose any file - you should choose changeset.

You can free to migrate any changesets from one version of your product to other, remove it, receive differences etc.

All changesets are stored in special database of TrueChange.