This is an update on the current state of Ivercy. I share some things we worked on in the recent past, things we are working on right now, and a hint of future ideas. - And, there is a new beta version released.

Long time, no see

During the last months we received a couple of inquiries if Ivercy is still supported and actively maintained and when there will be a new version out and the likes.

I can understand the reasoning behind these questions very well. The last production version of Ivercy was only a small bug fix release after 18 months of no public release at all. This is a very long time and it might indicate that a software product is (nearly) dead.

The positive side to this is, there were no significant bugs found in Ivercy (except the one that triggered V1.2.5) that would have required a bug fix release.

While I’m very proud of there being no severe bugs in Ivercy, there are still lots of issues that definitely are annoying and should be improved. We voiced our dedication to improving things repeatedly but without committing to any date for a new and improved public release.

Beyond MSSCCI - Ivercy BETA Version 1.3.10 released!

Despite all the above, we have not been inactive regarding Ivercy in that long time.

It was a key feature and requirement for Ivercy from the start that we use Microsoft’s MSSCCI-API as a general interface to any version control software (in theory) instead of concrete implementation of the APIs of distinct systems.

This allowed us to support a variety of systems like Team Foundation Server, Visual SourceSafe, Sourcegear Vault, Source Anywhere, and several others with the same feature set as the Microsoft SCC-Plugin for Access right from the start. Even in hindsight, this was the right decision to get a broad basic support of a variety of common source code control systems.

However, there were a couple of drawbacks with that approach. There was no reliable Git-MSSCCI-Provider available while Git was gaining more and more attention in the developer community. The Subversion MSSCCI-Providers where somewhat lacking, particularly in performance, and finally Microsoft decided to remove the required components for their TFS-MSSCCI-Provider from current versions of Visual Studio/Team Explorer, forcing Ivercy users to additionally install VS/TE 2013 to get the Ivercy system requirements for TFS connectivity.

To address these issues, we underwent a major redesign in Ivercy’s core architecture to move from the close coupling to the MSSCCI-API to a more flexible and pluggable architecture. This has become available with the Ivercy Versions 1.3.* quite some time ago already, but it was only available to certain customers upon request.

Today we released Ivercy Version 1.3.10 as a beta release download to the general public.

This release is a bit of hybrid version regarding its beta state. If you use the MSSCCI-Connectivity to your SCC-Backend, this version should be production-ready, and you can use it with little concern. But keep in mind, that internally there were huge changes to the internal plugging and there is a possibility of bugs nobody has spotted yet.

Improved Subversion Support with SharpSVN

The first actual connectivity implementation using this new pluggable infrastructure is available now! It’s a new, optional connectivity to Subversion using SharpSVN (an open source library). This should significantly improve the performance of Ivercy with Subversion.

This is in use by select early adopters for quite some time and it should be reasonably stable for production use. – However, a wider user base will surely find some problems that where not noticed before.

Team Foundation Server connectivity without MSSCCI?

Microsoft has made it more complicate to use the MSSCCI-Provider for TFS, by removing the required base libraries from current versions of Visual Studio and TFS-Team-Explorer.

Despite Microsoft assuring us that they are dedicated to support the MSSCCI-Technology in the future, it’s still quite a nuisance to many of our customers and to us that they are making it harder to use it.

We are currently investigating options to connect Ivercy to Microsoft TFS without using the MSSCCI-API. – This is also something that has only become possible by switching to the new internal architecture.

Current shortcomings of the new Ivercy architecture

What is currently is lacking, is the appeal of some UI elements in that regard. With the MSSCCI-API it was the responsibility of the MSSCCI-Provider to also provide user dialogs to establish a connection, filter the history, display history-query-results, and so on.

When not using an existing MSSCCI-Provider to connect to a source code control backend, all those integrated UI elements are not available any more. So, we need to create our own. This is harder than you might think at first. Different version control systems use different concepts, different terminology and structure information quite differently. We need to account for that but still try to create universal interfaces to accommodate all different systems.

So, admitted, our user interface in the new SharpSVN-Subversion interface is very, very basic and provides only a minimal functionality while not looking pretty.

Further plans…

We’ve got many other ideas to extend and improve Ivercy. - One could be obvious, if you read between the lines of this text. – But still I refrain from committing to any schedule. Nevertheless, be assured that Ivercy will not only supported in its current state but also enhanced with new features in the future.

In June 2017 the public downloads for TFS Team Explorer 2012 and 2013 were removed from the Microsoft website. The links we previously included in our Getting-Started-Guide for Ivercy and TFS suddenly were only leading to a page saying: “We're sorry, this download is no longer available.”

Team Explorer is a mandatory system requirement for the TFS-MSSCCI-Provider, which Ivercy needs to connect to Team Foundation Server. So, this is a major change for all Ivercy customers who are using Microsoft Team Foundation Server as their source code control solution.

I assumed these public downloads were removed in error and contacted Microsoft Support about this issue.

In the email conversation with the very helpful support technician I was able to establish several facts.

• The public Team Explorer downloads were removed intentionally, though the rationale behind that change were not disclosed to me. The TFS-Team at Microsoft is aware of the fact that this makes it more difficult to obtain a working installation of the MSSCCI-Provider for TFS.

• Team Explorer 2013 is still available for free by download from the Microsoft website. However, you now need a free Visual Studio Dev Essentials account to download Team Explorer. (It is available via MSDN-Subscription as well.)

  If you are logged into your Dev Essentials or MSDN account you should find Team Explorer 2013 in the download search results by using this link:  https://my.visualstudio.com/Downloads?q=visual%20studio%202013%20team%20explorer

• Even though it is now slightly harder to get the prerequisites, the TFS-Team at Microsoft will continue support for the TFS-MSSCCI-Provider in the future.

The bottom line is, there is nothing serious to worry about. The Visual Studio Dev Essentials account provides many free benefits for developers, like free developer tools, free subscriptions to training and credit for Azure services. It is a sensible decision for any developer on the Windows Plattform to get a Dev Essentials account. (Unless you got a MSDN subscription anyway.)

However, once again Microsoft completely failed to communicate this change in tool availability to the developer community. It would have been easy to include a short text on the “download is no longer available”-pages, explaining how to get Team Explorer from now on. This would have been the sensible thing to do. It would have saved many of developers from the tedious search for alternative download locations and would have prevented multiple unnecessary support cases.

Note: Japanese is the most relevant Asian language for us, as we had multiple request from developers in Japan, who would like to use Ivercy, but can’t for the reasons described in this post. So I frequently refer to Japanese in this post, but the issues are the same for any Asian language!

The last couple of days I struggled with supporting the Japanese Language in Ivercy. Today I have to admit defeat. - And I’m not doing this lightly.

There are two problems with using Ivercy in a Japanese language environment. As you probably are a software developer yourself and maybe interested in that, I’m going to describe the issue with quite a bit of technical detail. If you are not interested in that kind of detail, skip right to the bottom line.

The UI-Problem

The integration into Access is partially dependent on the UI-Language selected in Office. So Ivercy needs to know and understand the Japanese terms for Query (???), Form (????), Report (????) and so on. This is required for the UI-Integration into the Navigation Pane.

Access and the .net Framework, which Ivercy is implemented in, use Unicode Strings. So any character set can be represented in a simple string. So, this first issue can (and is) solved by simply adding a translation table between the Japanese terms and their English counterparts. This solves the UI-Integration issue and will be included in the next release of Ivercy (version 1.2.+x) and will be available soon.

The MSSCCI-API- Problem

The second issue with supporting Japanese is the MSSCCI-API. Unlike any Win32-API, the MSSCCI-API has no Unicode (…W) declaration/implementation of its functions. The functions are only available in an ANSI implementation, which uses the LPCSTR-Type or an array of LPCSTRs for character data.

Codepages and character encoding

With Western languages that can be represented by the Windows Codepage CP1252, it is fairly easy to pass data to the functions of the API. You simply declare the LPCSTR parameters as Strings and you are good to go. The .net runtime will sort out the marshalling of the data automatically.

Now, if you have got a file name (derived from an object name in Access) that consists of Japanese Characters, it will be automatically mapped using Codepage 1252. The result will be something like this: “????????????????”. - The question mark replaces any character that cannot be properly mapped. As CP1252 was never intended to represent Asian Characters, none of them can be mapped and the resulting data is completely unusable.

Now, the .net Framework supports all Windows Character Encodings, so it is possible to convert the Strings using the appropriate Codepage for Japanese (CP932). The result is a byte-array containing the string’s representation in the correct Codepage. – So far, so good.

Marshalling in the .net runtime

The conversion to the correct Codepage leaves us with an array of bytes that represent the Japanese character string

Now, for simple LPCSTR parameters it is pretty straight forward to implement. You would use an Byte() type in the declaration of the function and just pass our array of property encoded bytes to that. – Done.

Unfortunately, it is not that simple. Most of the functions in the MSSCCI-API do not use just simple LPCSTRs, but arrays of LPCSTRs. They would translate to an array of byte-arrays in our declaration – Byte()().

Other than a String or a simple byte array, the .net runtime cannot automatically marshal nested /jagged arrays. It should be possible to write a CustomMarshaler that would handle the marshalling of these types. There are actually some samples around on the internet. But I spend quite a bit of time trying to implement a CustomMarshaler for our jagged byte arras in Ivercy and simply could not get it to work. :-(

As I’m the developer with the most experience on WinApi and P/Invoke on our team, this is a pretty disappointing result.

Bottom line

You can use Ivercy in a Japanese edition of Microsoft Access and the icons and integration will work with the next version of Ivercy after 1.2.

But, you can only and strictly use plain English (western) characters in your object names in Access. As soon as there is any object in your Access database that contains a Japanese (or any Asian) Character, there will be exceptions all over the place and it will not be possible to work with Ivercy in that database.

We’re truly sorry about that. We might come back to this topic and try to address and fix the issues at a later time.

If you are an expert with Interop and P/Invoke in the .net environment and think you are able and willing to help with this, please get in touch. And we don’t expect your help for free.

I’m excited about the latest new feature in Ivercy. I call it Ivercy Local Change Tracking (LCT) and it’s really cool. Let me tell you a bit about it.

The problem with change tracking of version controlled Access files

If you ever worked with the Microsoft Source Code Control Add-In in Access, you most certainly know the problem. Someone else in you team has changed a file (an object in Access) and you know nothing about it. Maybe the SCC-Add-In displayed the Checked-Out-Status for some time while you colleague was working on it, but it changed to Checked-In after a while and you do not know if your team member actually changed something or just undid his changes. If you actually noticed it and are interested, you could do a Diff of your local version against the repository and will see any changes, but that is a hassle. It is like flying blind.

It might get even worse. You absolutely know someone else has changed a file because they told you, or you even did it yourself on another computer. You select the form, report or query in Access in and hit the Get Latest Version button of the MS-SCC-Add-In. – And…

…it doesn’t get it. It just does nothing. You know the changes are there, but you just can’t get then. – Frustrating. The only thing that helps here, is deleting you local copy of the objects (forms, reports, etc.) , including it’s temporary file in the working directory and then get the latest version from the repository.

One of the underlying problems is, that you are not working directly with the source files, but with their representation in Access. Access changes the contents of the files while you are just importing them. So you are working on an incarnation of the file that might be different from it’s current source file, but these changes are irrelevant. If you actually modify the file yourself, the changes suddenly matter, but from the technical point of view, the MS-SCC-Add-In can not tell the difference.

Ivercy Local Change Tracking

The change tracking features of your SCC-Provider simply can not track changes to the objects in Access. They don’t see those objects there because they know only about the files.

So here comes Ivercy Local Change Tracking. Ivercy is a version control add-in that runs within Access. It’s Local Change Tracking feature calculates and tracks it’s own checksums not only of the files, as the the SCC-Client will do, but also of the objects within Access. This allows Ivercy to know which objects are still matching the source files in your local working folder and it is able to highlight those objects that don’t any more. It does not matter if you checked out an object or not, Ivercy shows you, if you modified the object. That is what matters much more than the former.

See this screenshot of the Access Navigation Pane. In addition to the usual icons for Checked-In, Checked-Out, etc. it has small informative icons that show you additional status information. The small asterisks indicate that you modified an object. Your local object is different from the version you pulled from the repository. And it does not matter if these changes are only in Access or already synced to the files in your local working folder.  Ivercy recognizes both types of changes and marks them for you. – This is great, isn’t it?

But wait, it get’s even better. The most annoying problem described above weren’t your own changes, but the changes of someone else. These changes have to be tracked by you SCC-Client as they are only available in the repository yet. But the good thing is: Ivercy visualizes these changes other team members did to you. See the red exclamation point next to some files SCC-Status-Icons? These indicate that there is a newer version of that object in the repository than you have got on your local computer. – So no more flying blind. You see what really goes on with file and Access-Object modifications.

And as an explicit side note to the Subversion users and all others who favor Edit-Merge-Commit: This is extremely valuable help in your style of working. You are not so dependent on the Check-Out/Check-In-Stuff any more if you want to be supported visually by your SCC-Solution.

This also proves some of the points I made recently in defense of the MSSCCI-API for the use with Edit-Merge-Commit.

Ivercy Local Change Tracking is not yet included in the current version (V0.9.11) available for download. It will be included in the next release of Ivercy.

This blog post describes only the most obvious benefits of Ivercy LCT, there is even more to it. Stay tuned for further updates.

Why don’t you sign up for the Ivercy newsletter, to be among the first to know? Or join our beta program to test Ivercy right now!

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:

• Push OK SNVSCC - http://www.pushok.com/software/svn.html
• TamTam SVN SCC - http://www.daveswebsite.com/software/tamtamsvn/
• Agent SVN – SCC - www.zeusedit.com/agent/
• fire-development SVN-MSSCCI - http://www.fire-development.com/produkte/svn-msscci/
• Aigenta Unified SCC – Seems to be not existent any more.

· 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.