Board index » delphi » Programming tip: Version control

Programming tip: Version control

Some years ago I found a nice solution for the version control problems
that were rising. Due to the increasing amount of units, it became almost
impossible to write new versions for existing units and save them under a
new name. Perhaps for the die-hards here, it is old stuff or there is an
alternative which is much, much better.....Perhaps it is a re-invented
wheel.
Fact is: To me it has been very useful and so far I saw nobody use the
same trick while many experience the same problem.

Comments are appreciated, as long as they are positive :-)

Femme Verbeek

INTRODUCTION
Since Borland Pascal has no build-in version control system, most
programmers will give new names to their programs or units before
compiling the latest changes. If a problem occurs, the new code can be
compared with previous versions. Sometimes its not clear whether the
problem is new or just newly discovered, so it is handy to be able to run
older versions as well, possibly compiled with the latest modifications
of the unit under construction. If you are recompiling old projects for
maintenance it would be nice to implement
the latest unit versions at an instance.

PROBLEM DESCRIPTION
The problem is best explained with an example. Program and unit names
contain a number that is increased for every compiled modification.
E.g.
Program P1; ....  Uses A1, B1, C1;
Unit A1; .......... Uses B1, C1;
Unit B1;..........  Uses C1;

Assuming that you still put the compile name of the program in the code
(standard pascal), an upgrade of the program involves 2 actions:
1 Program P1 changes into Program P2
2 The new code is saved as P2

If the modifications are in Unit A1, a total of 5 (= 2+3) actions must be
performed:
1 the line containing Unit A1 is changed in Unit A2
2 the unit is saved under the new name
3 in the Uses clause of P1 the version number of A is increased
Except the uses clause, no code changed has changed in P1, but to be able
to recompile the old version of P1, it has to be upgraded as well, which
requires the same two actions of the first example.

Similarly you can show that the number of actions equals 2+3+4=9 for an
upgrade of B and equals 2+3+4+5= 14 for a C upgrade. With an increasing
number of Units the number of actions increases quadratically. In
practice not every unit will use each of the lower ones, but actually
that only complicates matters. Even if a unit does not use the the lower
modified one directly, in most cases it will still need upgrading since
other units it uses were upgraded.
Furthermore an enormous amount of almost identical code-files is
generated this way and you don't want to know what strange errors occur
if one of the units uses the wrong version of another unit.

HERE'S  THE TIP
It is possible to construct each  individual Uses clause for each of the
units at compile-time using conditional defines and an include file. The
program and the units contain a number of conditional symbols (keys) and
an include statement in the uses clause. The keys determine which of the
units are included in the constructed uses clause.
A conditional symbol is defined by     {$DEFINE KEYNAME}
For each of the keys the include file contains a conditional compilation
directive.
{$IFDEF KEYNAME}     , UNITNAME       {$ENDIF}

In case of the KEYNAME being $DEFINEd, the unit or program this is
compiled as

,UNITNAME

else it is skipped.
Each Uses clause takes the form of

Uses   DUMMY {$I INCLUDEFILENAME} ;

The uses clause, being just a single statement, starts out in the
compiled unit (or program), continues in the include file and ends back
in the unit where it started. The Include file contains only part of a
statement. Since the $defined keys remain valid in the include file, but
not outside the borders of the compiled unit, each of them can get its
own set of used other units while compling the same includefile.

The DUMMY unit is necessary to overcome the problem of the starting comma
. In most cases it will not be necessary since most programs use at least
one of Borland's standard units that need no version control. E.g.
DOS,CRT

In the above example uses clause of the program P1 would be something
like

{$DEFINE UNITA}
{$DEFINE UNITB}
{$DEFINE UNITC}
Uses   DUMMY {$I UNITINHR.PAS};

The include file would contain

{$IFDEF UNITA}       , A1      {$ENDIF}
{$IFDEF UNITB}       , B1      {$ENDIF}
{$IFDEF UNITC}       , C1      {$ENDIF}

Since the all the of keys UNITA .. UNITC are $defined in the program this
compiles into

Uses   DUMMY,A1,B1,C1;

Unit B1 would only have the UNITC key and the unit A1 the UNITB and UNITC
key.

ADVANTAGES
The include file contains the name references of the last compilation. If
an old program is recompiled, it will automatically include the latest
version of all of your units. If an older version is needed, all that has
to be done is to reverse the version-numbers in UNITINHR.PAS . Suddenly
this has become very flexible, hence it is also possible to reverse just
one or two of the version numbers, which would have been very complicated
in the old system.
No guarantee that it will compile though. That depends on your backward
compatible programming skills.

Upgrading any of the units requires never more than 3 of the above
actions. Besides the upgrade of the unit itself, the only thing to do is
to increase the
version number of the corresponding name-reference in UNITINHR.PAS.
Since the higher units and the program do not change at all it is not
necessary to upgrade them.

Femme Verbeek
F...@{*word*104}jet.nl

 

Re:Programming tip: Version control


Quote
In article <tu3t889r4e4...@corp.supernews.com>, Femme Verbeek wrote:

> Some years ago I found a nice solution for the version control problems
> that were rising. Due to the increasing amount of units, it became almost
> impossible to write new versions for existing units and save them under a
> new name. Perhaps for the die-hards here, it is old stuff or there is an
> alternative which is much, much better.....Perhaps it is a re-invented
> wheel.
> Fact is: To me it has been very useful and so far I saw nobody use the
> same trick while many experience the same problem.

> Comments are appreciated, as long as they are positive :-)

> Femme Verbeek

I would recommend using CVS. By making separate checkouts on earlier versions,
one can check with older versions. It is also space efficient.

Most open source projects use CVS. It is free, but commercial support can be obtained.

Biggest drawback seems to be that the windows server is not yet reliable, so a linux or freebsd
box (as server) can be handy.

Re:Programming tip: Version control


"Marco van de Voort" <mar...@toad.stack.nl> wrote in message
news:slrn9u4pdr.1n6.marcov@toad.stack.nl...

Quote
> In article <tu3t889r4e4...@corp.supernews.com>, Femme Verbeek wrote:

> > Some years ago I found a nice solution for the version control problems
> > that were rising. Due to the increasing amount of units, it became almost
> > impossible to write new versions for existing units and save them under a
> > new name. Perhaps for the die-hards here, it is old stuff or there is an
> > alternative which is much, much better.....Perhaps it is a re-invented
> > wheel.
> > Fact is: To me it has been very useful and so far I saw nobody use the
> > same trick while many experience the same problem.

> > Comments are appreciated, as long as they are positive :-)

> > Femme Verbeek

> I would recommend using CVS. By making separate checkouts on earlier versions,
> one can check with older versions. It is also space efficient.

> Most open source projects use CVS. It is free, but commercial support can be obtained.

> Biggest drawback seems to be that the windows server is not yet reliable, so a linux or freebsd
> box (as server) can be handy.

Certainly a source code management tool such as CVS is better for development
environments that can support it.    But a methodology such as Femme proposes may
be useful for the lower budget, develop on my laptop, zip it up and go environment.

(Although when I have a multiple version question, the multiple versions go in
separate directories or zip files - the problem being is that unchanged units are
multiply redundant in each copy)

Re:Programming tip: Version control


In article <3be2bd99$0$11262$4c410...@reader0.ash.ops.us.uu.net>, Rufus V.

Quote
Smith wrote:

>> > same trick while many experience the same problem.

>> > Comments are appreciated, as long as they are positive :-)

>> > Femme Verbeek

>> I would recommend using CVS. By making separate checkouts on earlier
>> versions, one can check with older versions. It is also space efficient.

>> Most open source projects use CVS. It is free, but commercial support can
>> be obtained.

>> Biggest drawback seems to be that the windows server is not yet reliable,
>> so a linux or freebsd box (as server) can be handy.

> Certainly a source code management tool such as CVS is better for
> development environments that can support it.  But a methodology such as
> Femme proposes may be useful for the lower budget, develop on my laptop,
> zip it up and go environment.

CVS can be run on any humble 486 machine without problems.

One can also install it on the system one is working on, but the server is a
bit of a problem. Afaik the server only runs under unices, not Windows.
My default OS is FreeBSD, but for the average Borland user that probably is
a problem.

There is also Delphi based FreeVCS, that is more Windows oriented

Quote
> (Although when I have a multiple version question, the multiple versions
> go in separate directories or zip files - the problem being is that
> unchanged units are multiply redundant in each copy)

I also like the way you can add comments to the sources, and the fact that
CVS fixes problems with lineseparators decently (which is a plus if you work
in mixed dos/windows <-> Unix environments)

Other Threads