Hidden table with Commit History?

[AndrewM-]

I am just trying to reconcile how source control fits in with making backups of the accdb file using the build in backup function. I use the backup function everyday before settling down to write code. If there was an internal table in the database which had the commit history, then I could see when I created a backup that matched the commit. Currently I am using Git for diffing to find out what I changed between backups. It might be a stopgap until Git integration is fully implemented. I might also have to use this solution long term, if I am changing the database schema and I can't automatically revert code due to schema change.

Sometimes I am working on problems that are too hard for me to create a roadmap in my head or even with my favorite mind mapping tool X-mind. In this case I will generally build a heap of components without knowing how they will fit into the final solution. When a few of the components are linked together, suddenly the issue gets small enough to solve. During this process of trial and error, I am fitting the pieces together in many different ways and making lots of big changes. In my limited attempts to use Git during this stage, I have found that diffing commits is not that useful as the big architectural changes to my application mean that diffing results are mainly gibberish. I think that source code control comes into play when I have got past the basic design phase and want to evolve it to a better solution. Until I reach that stage, the old backup process works better.

If there was a hidden table in the accdb file with the Git commit history, then I could open any ms-access backup file and know where it was in relation to my Git versions. I am not clear on my thoughts and am just trying to figure things out.

[rubberduck203]

@AndrewM- Rubberduck has little to do with I think, so I'm going to close the issue, but I'm happy to help you work through this on this thread.

So, no. Rubberduck doesn't (and most likely never will) store any Git information in Access. Even if it is an interesting idea (and it is!), the add-in is meant to work with any application that supports VBA, so I don't like the idea of coding up an entire solution that's meant to only work in one of those environments.

Now, as for your problem, I'm assuming it's the code we're talking about, not the database schema. What exactly are you storing in Git? The entire accdb, or just the code modules? If you're experiencing this kind of trouble with the diffs, then it's very likely that your commits are too big. Try to commit more often. Also, may I recommend that you use Atlassian Source Tree as your Git client? It has the best visualization of any of the clients that I've personally used.

[AndrewM-]

I was storing the entire database in Git including table defs, query defs and form set up code. One of the main issues was that Git is case sensitive. For some reason, capitalisation in my code often changes by itself despite option explicit being used everywhere. That meant that most of the changes flagged by diffing were nonsense. The second issue is mainly related to procedures that are too big which resulted in nearly all of the procedures changing with every check-in. As a result of this experience, I have now started to extract methods as much as I possibly can to make the procedures smaller which helps isolate changes to where they actually occur. I am a self taught programmer (I am an environmental consultant actually) but so far I have only seen the message about programming for code re-use and the penny had to drop that refactoring to make small, single purpose procedures is probably more about making source code manageable than code re-use. I am now using smaller commits and Atlassian Source Tree and have reached the part of the learning curve where I need to learn to review pull requests and interact with tracking repositories. Pretty soon, I am going to give your source code tool a hammering as I want to open source/jointly develop some of my ms-access applications.

[rubberduck203]

I'll get back with a proper response, but I found some resources on a case insensitive diff.

• http://stackoverflow.com/q/17380029/3198973
• http://stackoverflow.com/q/4998474/3198973
• http://stackoverflow.com/q/17868854/3198973

[AndrewM-]

I believe that there is actually a setting in .gitconfig or somewhere like that where you can get git to ignore case. I did find it and set it but it had no effect. That was using the standard git for windows default diffing tool. If it is just a setting in git, then the issue should be easy to resolve. Thanks for the links, at least they reveal the scale of the issue.

[rubberduck203]

Ahh. Yes, that setting that you found ignores the case of filenames & paths. It has no affect on diffs. Maybe a different VCS would be a better choice? Now I'm wondering if Git is the right choice at all.

[rubberduck203]

Mecurial's out, but I'm wondering if we couldn't have a "code cleaning" tool option that fixes casing before putting it in the file system. It would be a bear, and slow things down, but might be the only thing that makes any VCS useful for VBA code, beyond simply keeping a history of changes. Mat's done enough work on the parser that I should have everything I need to do that.

[AndrewM-]

That is really good, at least I know why the case keeps changing. I tend to use the same local variable names in most of my procedures and it seems last in wins when it comes to declaring variables. I think that the solution is to scan all variable declarations and to ask the user to choose the capitalization when there is more than one variation of capitalization for the same name. That would effectively be a case-sensitive find and replace. The preferred capitalization could possibly be persisted somewhere in the current project. Bear in mind that I have the version of RD where source control is not working (1.4.3) so I have not had a chance to see how git works with RD.

If you wanted to create a code cleaner, then a simple rule would be that the option with the most capital letters wins. Usually I use PascalCase but sometimes use camelCase with a small head so converting camelCase to PascalCase would be the preferable option.

[rubberduck203]

The problem shouldn't be variables names. Variables should be all camelCased by convention. The real issue is when you have a PascalCased property and a camelCased variable that both use the same name. This causes a conflict that fraks with casing in a real bad way. The way Rubberduck works with Git is like so.

1. Commit button is pressed.
2. Rubberduck exports all code files to a user defined file system directory that just happens to be the location of a Git repository.
3. RD adds any untracked files to the repository.
4. RD tries to commit any & all modified files (including adds/removes).

It's more or less the same thing you can accomplish by hand, or by using other export methods.

Incidentally, that blog post is exactly a year old. =)

[rubberduck203]

What I'm trying to decide on right now is if it's worthwhile to create a step after the file has been exported that updates class/method names to PascalCase, etc. prior to performing the commit.

@retailcoder, do you think that's possible with our current parser? I think there's still an overload exposed that takes a string input, correct?

[retailcoder]

@ckuhn203 it's a public member of the RubberduckParser class, but not a member of the IRubberduckParser interface... but I thought you wanted to keep SCI distinct from the GPL code? ;-)

Also, we might not want parser errors to break SCI.

[rubberduck203]

I do, but the benefit might outweigh the cost. Either way. I need to make The GUI integration actually work first anyway.

[rubberduck203]

Well.... I could always implement a new ISourceControlProvider too. That would save the MIT license on the library code.

[retailcoder]

@ckuhn203 it would be a shame to put tons of efforts into getting the WinForms UI to work, only to re-implement it in WPF/XAML for 2.01 - how close to "working" is the SC UI?

[rubberduck203]

I haven't made a commit in months. No idea what's even wrong with it right now.