By chance I came across this support page of Visual SVN during some research on Subversion. It tries to explain why VisualSVN is not a generic MSSCCI/SCC provider. I include a screenshot for your convenience.
After reading this, I have to comment on this a little. Not because I want to flame the VisualSVN-Team. They are doing a great job! But I think this a quite common view of the MSSCCI-API, which I encounter frequently when talking about it. - I think this view is wrong in several ways.
And while this view of MSSCCI was originally expressed in the context of Subversion, my comments are not at all limited to the Subversion context, but apply to all SCM systems that favor the Edit-Merge-Commit style of working.
BTW: MSSCCI is the abbreviation of Microsoft Source Code Control Interface.
OK, let’s look at those statements one by one…
· MSSCCI is dedicated to Visual SourceSafe and is not compatible with Subversion;
Well, what does “dedicated” mean here? Of course MSSCCI was designed with SourceSafe in mind and was certainly supposed to fully support and cater to Microsoft SourceSafe. But MSSCCI is certainly not dedicated to SourceSafe in a way that it is not suited to work with other systems.
Why do they claim it “is not compatible with Subversion”? That is certainly not true. The inner circle of SVN developers has chosen not to support MSSCCI, right. But MSSCCI is just a specification. If someone wants to implement it with a Subversion client he just can. There is nothing incompatible there. And there are actual implementations available at the moment, to prove this. Just a list of those I know of:
· MSSCCI is dedicated to Checkout-Edit-Checkin approach, but Subversion is built for Edit-Merge-Commit;
“Dedicated” again. Yes, Checkout and Checkin are actual terms used in the specification. As I wrote above, MSSCCI was designed to support this well, but it is not dedicated to it in a way that would prevent you working Edit-Merge-Commit style.
You can just edit your local copy of a file without Checkout, there is nothing in the MSSCCI spec that prevents you doing this. – Visual SourceSafe will actually try to do so, but that is a different matter. (MSSCCI is an API-Specification, SourceSafe has (not is!) an implementation of the API.) And there are File-Status defined in the spec that support the edit-without-checkout approach well.
If you edit a file, you can merge it with the current version in the repository any time. It is the job of the actual client implementation to support this well. There is nothing in the MSSCCI-Spec that prevents any client from doing this.
When it comes to commit, there is actually a little difference there. When using a MSSCCI based implementation, the client would have to do a checkout followed immediately by a checkin of the modified file. That is not ideal as those are two independent operations that have to be coordinated on the client, so it is not atomic. If the client fails in between, it will leave the file checked out and unmodified. – But that is just in case something goes wrong unexpectedly.
· MSSCCI doesn't provide atomic transactions;
As said above regarding the “commit”. There actually is a weakness (you may call it flaw) in the Spec as it does not define an atomic way of combining several independent operations in a transaction.
The MSSCCI spec actually defines a way to group several independent operations together as “Batches”. (See SccBeginBatch / SccEndBatch). However these where not specifically meant to control transactions. As far as I know, most Development Environments that support MSSCCI do not support the Begin/End-Batch API at all.
So I have to admit, the spec makes it rather difficult to implement transactions covering multiple different SCC operations.
· MSSCCI provider can't show status of folders;
That is correct. - But is that a serious issue? I don’t think so! A folder is a container for individual files. I do not care much about the state of the folder. I’m just interested in the files. And any IDE could still display a folder status based on the status of the files it contains.
· only one MSSCCI provider is available at this time. There are use cases where Subversion and Visual SourceSafe controlled projects are used together in one solution.
Right, the MSSCCPRJ.SCC File, which stores the SCC bindings of a project according to the MSSCCI spec does not define a way to store which provider is used for this project. And I agree, there should have been a way to do this. Currently on Windows there is only one default MSSCCI provider defined in the registry. So most IDEs will only be able to use the default provider for all projects within one solution.
That is somewhat annoying. When creating entAscc, I wanted to work around that. Ivercy explicitly stores the provider to use for one project in it’s own configuration file for the project. That is absolutely possible while being MSSCCI compliant. – But it is not covered by the MSSCCI spec of course.
So my overall bottom line is:
There definitely are some aspects of the MSSCCI spec that are not ideal. Some things should have been specified in a more flexible and open way. But what I see as the core critique in those reasons for Visual SVN not supporting MSSCCI, being dedicated to SourceSafe and Checkin-Edit-Checkout and not being compatible with Subversion and Edit-Merge-Commit, is simply not a substantial case against MSSCCI.