Support the MS SCC API

[mansellan]

The Microsoft SCC API provides a means of interacting with multiple source control systems. It was originally implemented for Microsoft Visual SourceSafe, but subsequently achieved wider usage. Previously, the API was proprietary, requiring an NDA before Microsoft would provide documentation, however they have now published the spec openly.

Essentially, the developer installs one or more SCC providers on their development machine - canonically this would be the Visual SourceSafe provider, however many others are available (see below). The application to be source-controlled then talks to the provider on the local machine, either natively or with an add-in, and passes data to it by way of exporting source files (similar to how RD operates during parsing). The provider is then responsible for storing the data in the repository:

App ---> [Add-in] ---{SCC API} ---> Provider ---> Repo

There can be multiple providers registered at any time on the developer machine, however only one is considered to be the active default at any time. Tools exist to either switch the active provider, or even to transparently select among many based on a given project's connection data.

Providers exist for many different repositories:

Visual SourceSafe SourceGear Vault Perforce P4 Team Foundation Server (requires Team Explorer 2013 installed) Rational Team Concert (provider is an installable option bundled with the RTC client) Mercurial (open source, no longer maintained) SVN (commercial, paid) CVS (commerical, paid) Git (commercial, free (during beta?)) (list not definitive)

Host applications which support the API either natively or through add-ins:

Access <= 2010 (MS Add-in - see below) Excel 97 (!) Developer Edition (MS Add-in, feature-lacking and abandoned) SQL Studio <= 2015 (native) PowerBuilder (native) (list not definitive)

By supporting the API directly in RD, we can make basic source control available to any VBE host:

App ---> VBE ---> Rubberduck ---{SCC API} ---> Provider ---> Repo

Whilst the API only supports a basic working model - centralised and lock based - supporting it would have the following benefits;

1) It would add support for a large number of repositories in one hit. 2) The simpler model should translate into an easier implementation. 3) The API gives us an easy way to mock and test 4) The API gives us an easy support limit - we would not need to get involved in issues arising from the provider(s) or the repos.

Challenges would include:

1) Factoring the SC feature of RD (currently Git only) to allow selection of multiple source control systems 2) Learning how to use \ wrap the API 3) Adding the functionality without further destabilising SC (ideally, strengthening it)

Previously, MS SCC integration was possible in Microsoft Access up to v.2010 using a plug-in from Microsoft - anecdotally I believe this was fairly widely used. I suspect the lack of source control support from Microsoft for recent Access versions has left many developers in a tough spot, so this could be a popular feature.

[Vogel612]

FWIW the "centralized and lock based" working model seems like a crass simplification. I could even imagine writing a libgit2sharp git provider that follows the same wrapped API.

I'm pretty sure we can rewrap the currently existing API into something more stable, especially when SSC has a proper and stable API (which is strongly suggested by the variety of source control systems interacting with it) ...

[mansellan]

Addendum:

Following the withdrawal of support for the Access SCC plugin, other options have been made available:

Ivercy - A direct replacement for the MS Access SCC add-in (commercial, paid) Oasis-SVN - Connects natively (without MS SCC) to SVN, Mercurial, Git. (commercial, paid) msaccess-vcs-integration - VBA-native solution for SVN, Git and Mercurial (Open source) MSAccess-SVN - No longer maintained (Open)

[rubberduck203]

Gagh! This is very much what I imagined early on.... Oh well. That is life.

We decided in #3758 to remove the feature.