Contents (updated: 04 May 2004).

1. Overview.
2. The supported features.
3. Upcoming features.
4. How the system works.
5. ISCCItem and ISCCBridge interfaces.
6. BridgeServer web service.
7. BridgeConsole command line tool.
8. Using of ISCCBridge interface in applications.
9. Using of SCCClient library in applications.
10. Requirements, installation and sources.

1. Overview.

SCCBridge is a client/server solution designed to provide remote access to wide spectrum of version control systems. The client-side contains the library for communicating with the server and console application. The server-side is implemented as a web-service with the interface to an external version control system (repository). The published interface that is accompanied by documentation allows implementing bridges to many of existing version control systems. There is another ability - to implement web client programmatically, so, any user's application can take advantage of using of version control system. SCCBridge is faster than the Visual SourceSafe Explorer access (via FTP or another type of Internet connection) because of:

• Only required information is passed between client and server;
• Using of file compression;
• Lack dependences of a network share.

In contrast to existing solutions this solution does not implement its own version control system, but just allows using of existing systems through Internet. It provides also common interface for your applications to a version control system supported by the web service.

Both the server and the client are written in C# in Microsoft Visual Studio .NET. In the project is used library SharpZipLib created by Mike Krueger (for more info see http://www.icsharpcode.net/ ). The algorithm for text files comparing was taken from The Code Porject site, and was written by Shankar Pratap.

2. The supported features.

The current version supports following version control system operations:

• Add files and/or projects to the repository;
• Delete files and/or projects from the repository;
• Check-in files and/or projects;
• Check-out files and/or projects;
• Undo check-out files and/or projects;
• Create label for files and/or projects;
• Get latest version files and/or projects;
• Get labeled version of files and/or projects;
• Get specified version of files;
• Get history of files and/or projects;
• Show differences between files or file's versions;
• Get list of files/projects;
• Share files and projects;
• Create branches of files and/or projects;
• Move files and/or projects into the repository;
• Pin/Unpin files;
• Mark/unmark projects as cloaked (this option is very useful when you are working via Internet and have a branch of subprojects only part of them you are interested in).

The current version includes the client-side library for access to the web-service, console application, GUI client-side application, unit for integration in Visual Studio .NET 2003  and the web-service itself that works under IIS 5.0 (and higher) and two implementation of ISCCBridge interface. The first implementation is used for remote file system access that emulates restricted version control system. The second one is more useful and is used for access to Visual SourceSafe database. The bridge interface is implemented as open source part and is accompanied of documentation.

3. Upcoming features.

In the next versions of SCCBridge project the following features will be implemented:

• Implementation of ISCCBridge interfaces for CVS;
• Thin client working on browser;
• Communicating with deltas only;
• Complex selection from the repository history;
• Implementation of ISCCBridge interface for MS SQL as a repository.

4. How the system works.

As it is mentioned above, the project consists from two parts: client and server. The client-side deals with local files and folders. It is designed for synchronizing of all changes with the repository on the server-side. The server-side processes requests and communicates with the repository through ISCCBridge interface. The diagrams below (figure 1 and 2) demonstrate stages of the "check in" command execution on the both sides.

Figure 1. The client-side.

1. ■ get the repository state.
2. ■ retrieve the repository state in the XML format as compressed DIME attachment.
3. ■ send the changed file (File2 e.g.) to the server as compressed DIME attachment.
4. ■ retrieve new timestamp for the File2 and set it.

Figure 2. The server-side.

1. ■ a client requests for the repository state.
2. ■ retrieve the with the repository state, compress it and send it to the client as a DIME attachment.
3. ■ retrieve the changed file, detach and decompress it. Modify the repository.
4. ■ get the new timestamp from the repository and send it to the client.

---