AbaPerls supports multiple version-control systems. OK, so it only supports Team Foundation Server and Visual SourceSafe, but two version-control systems is sufficiently many for AbaPerls to adapt an abstract view. This page discusses concepts in AbaPerls that are common to all version-control systems. There are also pages that discuss peculiarities for each supported version-control system.
AbaPerls supports two version-control systems, Visual SourceSafe and Team Foundation Server. The architecture is such that it would be relative easy to add support for a third and fourth version-control system. Not that this is planned to happen any time soon. And there is a caveat: different version-control systems tend to have quite different mindsets. This certainly applies to SourceSafe and TFS. AbaPerls has its origins with SourceSafe, and was SourceSafe-only for many years.
Some things in AbaPerls are designed to work the same, no matter the version-control systems, for other things AbaPerls attempts to adapt to the mindset of the version-control system. And not the least adapt to the capabilities and limitations of the version-control system.
AbaPerls permits you to use multiple version-control systems in parallel, but reasonably you would only use two systems if you are in a transitional stage, for instance on a migration path from SourceSafe to TFS.
If there are differences in concepts between SourceSafe and TFS that affects a certain command, this is noted the page for that command. There is also one page that discusses specific SourceSafe concepts and one page for TFS-specific concepts.
Three concepts are universal in AbaPerls:
The first point is described in detail on the page The AbaPerls Subsystem Structure. Here just a short recap: AbaPerls mandates a certain structure how to organise different versions of subsystems, and within each version how SQL files should be organised based on object type and file extension.
There are several places in AbaPerls where you provide a version specification. With the commands ABASQL, DBBUILD and DBUPDGEN you provide the version specification with the
‑label option. As the name indicates, most of the time your version specification is also a label in your version-control system. The version specification can also be a date or an explicit version number.
The exact interpretation of the version specification depends on the version-control system in question. Follow these links to see the rules for SourceSafe and TFS.
AbaPerls has a standard label format, LetterMajor.Middle.Minor which it uses to determine for instance, whether an update script is ahead, behind or in sync with a database. This format is further detailed in the section Label Conventions on the page The AbaPerls Subsystem Structure.
To access an item – file or a directory – under version
control you need a VC-path. You use the VC-path in system-definition files, in
config-files and most of all on the command-line as the argument with the
‑config. If you are using TFS, AbaPerls is able to map your
working folder to a VC-path, as discussed on the TFS
page. This ability is not available with SourceSafe.
A complete VC-path consists of three components:
The general format for this is:
VCsys is one of TFS or VSS.
The format of Repository depends on the version-control system. For SourceSafe a complete repository specification is the path to the DATA directory, for instance F:\Development\Our-db\Data. It can also be a UNC-path as in \\SSBOX\SourceSafeDB\Data. For TFS it is an URL with port number and virtual directory for the team project collection, for instance http://TFSRV:8080/tfs/DeaultCollection. Repository may have a trailing /. It is not compulsory, but very much recommended.
Within the repository, the path to an object – a file or a directory – always
starts with a
$ character, and directories in the hierarchy are
always separated by a forward slash,
/. Very conveniently, both
SourceSafe and TFS use this format internally.
If the VC-path includes characters special to the command-line environment,
such as space, you need to enclose the path in double quotes (
AbaPerls goes head over heels to save you from having to specify the VC-system and a complete repository specification, and many examples in the AbaPerls manual use an abbreviated VC-path.
Below follow the rules from two different angles. First how much you need to specify if you want to use SourceSafe or TFS. Then there is a list of the steps, AbaPerls take internally. But first a non-rule. AbaPerls does not check whether you have SourceSafe or TFS installed. Thus, even if you don't use TFS at all, you may still get an error message relating to TFS because AbaPerls made an incorrect guess. In the same vein, if you only use TFS you may still get an error message related to SourceSafe.
If you want to use SourceSafe:
If you want to use TFS:
These are the steps that AbaPerls take to guess, eh, determine whether you want to use SourceSafe or TFS:
\) anywhere, AbaPerls assumes that you are talking SourceSafe, since it cannot be a legal URL for TFS.
:) followed by a digit, the VC-path must be a TFS URL, since this is not legal in a directory path.
Note that if AbaPerls would add support for a third version-control system, it is likely that these rules would be modified, and the number of shortcuts would be reduced.
Copyright © 1996-2012,
Erland Sommarskog SQL-Konsult AB.
All rights reserved. AbaPerls is available under Perl Artistic License
This page last updated 12-06-13 9:49