Microsoft development tools (starting with Visual C++ 4.0) use the "Common Source Code Control" (SCC) interface to talk to source code control. Given the popularity of Visual C++ the SCC interface has become the most widely implemented interface between development tools and source code control implementations.
The main problem is that the SCC interface was designed for SourceSafe, not for anything like CVS. Mapping between CVS semantics and the SCC interface is awkward. The most straight-forward approach is to use CVS like SourceSafe, but that it about as smart as driving around in second gear.
My first approach was to write an in-process component that returned local status directly, and deferred the "heavier" operations to a "coworker" component. I documented the coworker interface, provided some sample coworkers implementations, and did the initial coworker integration with WinCVS. All that remained was for to implement the coworker methods with WinCVS (I didn't have time). That was a few years ago ... and no one picked up the ball.
Products believed able to use the SCC API:
Products that are known or believed to have implemented the SCC API:
As you might guess, I would like to add CVS to this list :-).
Microsoft Developer Studio 4.0 defines an interface for integrating source-code control. Once a source-code control system is installed that conforms to the Microsoft Common Source Code Control Interface, the user interface alters (added menus, appearance of files in project window) to reflect the operations offered by the source code control implementation, and to reflect the status of the files (if under source code control).
Unfortunately the documentation for the API is not publicly available. You can get the documentation of the interface from Microsoft, by signing a non-disclosure. The SCC API appears to be oriented more toward an RCS/SCCS/SourceSafe style interface - individual file check-in, check-out locked/unlocked, etc. Mapping CVS to this interface in any sort of intelligent manner should be interesting.
The SCC API documentation must be obtained from Microsoft, and Microsoft will ask you to sign an NDA (Non-Disclosure Agreement). The method for doing this has changed several times. Originally the way to do this was to send mail to firstname.lastname@example.org but this email address is no longer monitored. For a while we had a direct contact at Microsoft, but this was frequently abused (for unrelated purposes), so this was changed to require going through Microsoft Support. Going through Microsoft Support proved ... challenging ... as the humans involved in Support generally didn't have a clue (with some notable exceptions).
The current point of contact (as of July 2000) is:
Visual Source Safe MSSCCI [email@example.com]I have not tried this path, so I can't verify this.
If for any reason the e-mail contact does not work, you may have to revert to the old instructions for going through Microsoft Support. Going through Microsoft Support is a lot less efficient. I was successful in getting routed (eventually) to the right place when I called on 7/21/99, but not without going through a couple humans who were relatively clueless on this subject.
Please try following these instructions before contacting me. I can guarantee you that dozens of people (those that I know of) have successfully obtained the SCC API documentation by following the instructions here.
This email message details what you will be asked.
Drop me a message if the above instructions don't work for you. Or even if they do work (I'd like to know...:).
|$Date: 2002-12-22 23:39:08 $||home|