I don't know how this tool works, it's been years since I last tried a source control addin. At that time, the process was abysmally slow but more important was that you had to remember to "check out" BEFORE you started modifying an object.
There was such an issue with Microsoft's own SCC plug-in for Access. And, I agree, this was a major nuisance.
AFAIK, all current source code control add-ins do not require to explicitly check out before making changes. For Git based version control, the Check Out step is generally no more part of the SCC process.
The real issue is that if Bob makes a bad change and checks it back in, I may not be able to work on my piece if Bob's change broke something I needed.
This is neither specific to Access nor to source code control. If someone breaks code in your project, there will be a problem.
Source code control just makes it easier to add or modify code, be it good or bad, in a shared project.
Working as a team requires a build manager and the build manager should be the only person who can check objects in and he has to thoroughly check them as well as all other objects before the new changes can be incorporated into the current build.
I strongly disagree with having a human person (=bottleneck) as gatekeeper to validate all check-ins to a system. This will slow down the development process to a crawl.
With Git any developer would usually check in into a local copy of the repository first, and only later will these changes be incorporated into the common shared source code in a "central" repository. - This would be were you could insert the human gatekeeper into the process, without creating too much of a drag. Nonetheless, I still discourage that.
Automated testing is the key to reduce the risk of someone checking in bad code into a project and breaking it for everybody else.
For larger projects we have an automated process in place, that after each check-in will ....
- create the project's Access file from source,
- (try to) compile the code,
- run our code quality checks (powered by MZ-Tools),
- run all Unit/Integrations tests for the project.
If any of these fail, the automation process will alert the offending developer and optionally other team members of the problem.
As this happens after the check-in operation in our process, it does not prevent bad code from being checked into the repository. But the alert to the relevant developers allows for a quick fix of the problem.
One could also change the process to automatically roll back such a bad check-in and thus prevent bad code from entering the repository.
