Version Control for VBA modules or projects? (1 Viewer)

[Mike Krailo]

What does everyone use for versioning control on their projects. It would be nice to use Git but since I don't know where the modules are stored at I cannot set it up. Anyone have a solution for this? BTW, I completely new to versioning control in general and have blundered my way through without it for quite some time but it's time to get organized now.

I have two different locations that I develop at and it would be nice to have a central repository for all the code and track all the changes on various projects.

 

[Minty]

Philipp Stiefel has an excellent guide for this here https://codekabinett.com/rdumps.php?Lang=2&targetDoc=choose-source-code-control-microsoft-access

 

[Micron]

I keep backups of the front end during development, file name & date of archive. How often and for how long would be personal preference and might be based on how much has changed since the last one. Unless you keep a separate db as a code library and call everything in it from a deployed fe, you really don't have a separate code file - unless you keep that as a document. I've never done that since I can keep all the code, query and report objects backed up as well. You never know when an object might get corrupted if it's being modified occasionally, so why not back up the objects as well? When I think I no longer need a version, it goes into my ToBeDeleted sub folder and I let it ferment there for a while.

EDIT - Forgot to say that since you mentioned working from different locations, I see no problem in storing a db on a stick or cloud - I just would never run it from either location.

 

[Mike Krailo]

Thank you Minty, that filled me in on some the details that I was thinking about. And Micron, that's a good reminder about not running from the cloud. I have been looking into the separate db code library thing as well. One of my developer friends has one and just started using it successfully.

 

[Lightwave]

The 3 2 1 rule seems to be sensible
Store 3 backups
Ensure they are in 2 locations (2 devices)
Ensure 1 is off site

I just use rolling backup scripts that takes unique seconds / days / weekly / monthly and yearly backups of the whole database
Particularly useful functions I will write up on my blog
And happy to backup up things to sticks / google drive

 

[NauticalGent]

Mike Wolfe has started a sort of "Version Control for Dummies" on his site. Here is the first article.

 

[Mike Krailo]

I have found it easier to understand the big picture using one of the many video tutorials on GitHub or GitLab to get started with version control. Then going through the Access specific add-ins later. There is a lot going on especially if you use different workstations like I do to keep everything sync'd up. Once you learn all the basic commands and how to resolve merge conflicts, working with different branches of code and merging into the main branch, then the apps like Oasis-SVN make more sense. That's what I'm using currently. I'll have to check out that open source msaccess-vcs-addin and see how it works. I love open source stuff.

 

[GPGeorge]

I have found it easier to understand the big picture using one of the many video tutorials on GitHub or GitLab to get started with version control. Then going through the Access specific add-ins later. There is a lot going on especially if you use different workstations like I do to keep everything sync'd up. Once you learn all the basic commands and how to resolve merge conflicts, working with different branches of code and merging into the main branch, then the apps like Oasis-SVN make more sense. That's what I'm using currently. I'll have to check out that open source msaccess-vcs-addin and see how it works. I love open source stuff.

There will be presentations on this add-in in one or more online Access User Groups in coming months. Working out scheduling is not the easiest task because people have their own ideas about priorities and family obligations and stuff.

 

[Pat Hartman]

I have my FE's configured to identify object changes and when I am the logged in user, ask me if I want to make a backup with I close the database. The backup makes three copies. One full file to my local drive. One full file to a network drive when I am working on site and one export to text version to my local drive. So, all I need to do while I am working is to simply close the database to get a backup. So I might have 10 backups for a day when I am doing heavy development. I very rarely have to go back more than one or two versions but I have on occasion gone back a month. Every few weeks, I delete old versions and move the oldest to a long term back up.

It's not a version control application - which I still miss even after being without one for the entire 25+ years I've been working with Access. I did have one client that used SourceSafe. I was very excited but it sucked. Not to mention being painfully slow.

 

[Josef P.]

In my opinion, a version control system should not be regarded as a backup system.
For me, it is a tool for daily work, just like the code editor.

Messages such as "Suddenly (meaning after the last update) an error occurs when ..." are resolved very quickly, as you have a good visual representation of the changes.
Example:
Change history: https://github.com/AccessCodeLib/AccessCodeLib/commits/master/data/SqlTools.cls
+ Changes of last commit: https://github.com/AccessCodeLib/AccessCodeLib/commit/18e2ff8c952bd16b66b8b95e69151dee0256be45
When displaying the commit details, for example, you can see the only small change in the code and the added test for this change.
This information is not possible with a backup of the database file.

msaccess-vcs-addin can in principle also be used without a version control system.
In this case, you lose the option of displaying the history, but at least you have text files that are easier to compare.

 

[Solo712]

Since as a developer I worked mostly by myself I had not seen the need for for versioning control products designed for the use of teams. But I learned in the school of hard knocks that it pays to maintain version control. I did it via table which recorded all code, report design and query modifications, additions and bug fixes (also column additions to tables in BE). It was rudimentary but I had found it quite effective. A user read back to me entries from the table (via form of course) and searched it, and that way I knew what needed to be fixed. Usually, I'd send the latest version of FE (with the version table). If table mods were done, I'd furnish the BE shell, and then either have the admin dump data to the newer version or I do it myself remotely.
As for version numbering, it was a judgment call when to call it a new major and minor versions. A release number however was incremented every time I sent a file to one customer or more, or when it made sense that modifications were bundled. The release number then specified if it was one for release for "distribution" or "package". A query would tell me who that particular release was sent to, or what mods and fixes were included in the bundle.

Best,
Jiri

 

[Pat Hartman]

In my opinion, a version control system should not be regarded as a backup system.

I don't believe I said it was. Access doesn't give us hooks into the MSAccess.exe that are intended to support source control so It wasn't something I was willing to even attempt except at a gross level. Exporting all objects as text is certainly overkill but at least it gives me versions of the ones I did change. So, yes, the tool ended up creating backups for safety but also rudimentary source control. Of course to take it to the next level requires a third party tool to compare file A with file B and identify changes.