• Messages sorted by: [ date ][ thread ][ subject ][ author ] [ Next ]
• [ Previous ] In reply to: Jonathan S. Shapiro

At 02:42 PM 6/12/00 -0400, Jonathan S. Shapiro wrote:
>This raises an interesting design question about history tracking: should
>recording be per-file or per-commit? I'm currently building on the
>per-commit assumption, but it's not too late to change that.

Let me describe the system used by IBM, and its customers to maintain the source for VM/370 (at least back in the "good old days"). It is quite different from CVS, and provided some features that were quite useful. (I will actually describe the Tymshare variant.)

All source consisted of a base source file and a set of deltas. (Deltas were based on sticky line numbers in the source files.)

A particular version of a source file was defined by a file which contained the list of deltas to apply to the base to get that version. (There was a complex scheme which permitted several versions to coexist in one file system.)

All of the files were tied together with a naming convention. Translating this convention to the Unix syntax, assume we have a source file foo.

The base file would be foo.asm
The deltas might be named foo.fixoverrun, foo.newfeatures etc. The list of deltas might be named foo.version2

All the deltas in a particular change have the same extension name, e.g. newfeatures. In the Tymshare variant, there is also a human readable file, newfeatures.script which describes the change. (Script is a runoff like text formatting language.)

The disadvantages of this system are:

• Every compile required that all the deltas be applied to the base. This became tolerable when a parallel delta application utility was written.
• Creating deltas was a pain. It became a lot easier when a diff was written, and even easier when that function was integrated with the editor.
• Merging changes from different people/organizations could result in sticky line number conflicts. I think most of these problems were inherent in the problem. (CVS has equivalent problems.)

The advantages were:

• Most of the disk space could be shared read-only between developers.
• It was easy to include/remove a change by editing the list of deltas.
• Changes across modules/systems/repositories were tied together along with their documentation by the naming convention.

[ Next ]
• [ Previous ] In reply to: Jonathan S. Shapiro