This document explains why and how Microsoft Visual Source Safe can be used for the source code control of projects that are based on Unix-based systems. (Unix-based systems are those that run any flavor of the UNIX operating system, e.g., Linux, HP-UX, IBM AIX, Sun Solaris).
Source Code Control on Unix:
Traditionally, SCCS has been used as the source code control system for Unix. This package (Set of programs) is usually bundled along with any Unix system. However, of late, the industry has seen movement towards using either RCS (Revision Control System) or CVS/RCS (Concurrent Versioning System over RCS). Both of these are distributed free with full source code under the GNU Public License (see http://www.gnu.org ). The latest stable versions can be downloaded by public FTP from ftp://ftp.gnu.org/pub.
The problems with using the above-mentioned source code control systems are mentioned in this section.
Here we are assuming that most of our documentation is done using Microsoft Office or other utilities on the MS Windows (Win95/Win98/NT/Win 2000) platforms. It is also assumed that we will work on the Unix projects through a Windows-based PC (either by using the telnet program or by using some kind of an X emulator).
1. Since we need to keep versions of the documents too, we will need to install Microsoft Visual Source Safe. If we use the above source code control systems, we will end up with having to maintain 2 repositories, one for the documents and one for the source. We will also have to constantly switch between the commands/functionality offered by the Unix-based source code control system and Microsoft VSS.
2. CVS/RCS is inherently difficult to use for teams that are not accustomed to the Unix-based interface.
The Suggested Solution:
Use a single repository by using only Microsoft Visual Source Safe. Even the code will be stored in the VSS. For the how of this, read on.
· Install SAMBA on the Unix-server where the development is expected to take place. SAMBA is an implementation (again under GNU free license) of the SMB (Server Management Block) protocol which Windows uses for its networking. For example, this is how Windows uses to "Find Computer" and "Explore" some PC in the Network Neighborhood.
· Configure SAMBA appropriately (see SAMBA documentation for more). Directories on the Unix-server can be "shared" like a Windows directory.
· Go to any Windows PC in the neighborhood and "Find Computer" giving the name of the Unix server…and, like magic, the Unix server shows up. Exploring will show the directories shared on the Unix server.
· What we have achieved is to fool the Windows PC in believing that the Unix server is a Windows NT server. Now, we can map any shared directory on the Unix server (subject to permissions, of course!) and this appears like a drive on the PC.
· Now, create a folder on the mapped drive and make it the "Working Directory" for the source code folder in Microsoft VSS. After this, any check-in / checkout of the source code will be directly transferred to / from the Unix-server.
· SAMBA has to be configured in the right way, which won't take a minute if you want the defaults.
· Security will usually be configured in SAMBA to use the Unix password mechanism. Each Unix user will usually have a login and a home directory on the Unix server. If we are using Win95/Win98 PCs to map Unix directories, the username that is used to log into Win95/Win98 should be the same as the Unix login name for that user. This problem does not arise with NT because NT prompts for a dialog box that allows the change of the username while connecting to a drive. Actually, this problem is something that is wrongly done by Windows and has nothing to do with SAMBA.
· VSS has to be configured to see files ending with .c, .h and other Unix source files as binary. If this is not done, VSS automatically puts in a
Maybe using CVS/RCS will still be useful for some projects. But, most of the project leaders should be happy to be using a single source and document repository.
Using SAMBA, directories on Unix servers can be mapped as Windows NT drives. One usage of this is to have Unix files stored in VSS and set the working directory to the appropriate folder in the mapped drive. (Other uses are to use the Unix server as a file server…for example, "Oh! I do not have enough disk space to install this software. But, I the Unix server have a lot of free space. So I can map that as a drive and install my software on that drive!).
In this way, Microsoft Visual Source Safe can be used for versioning files on Unix-based projects.