It's All About the Diff

In an earlier article, I wrote about how using version control made me change my default behavior when Access asked me to save changes to a form that I didn't recall making any changes to.

Before using version control

Before I used version control, I erred on the side of not saving my changes.  After all, I had no good way of isolating which changes I had just made.

After using version control

With version control, I don't worry about accidentally saving unwanted changes.  Now, my default behavior is to always click [Yes].

Counterpoint

My article sparked some discussion on a LinkedIn group where Mark Burns posted the following [shared with permission]:

Actually, I learned to choose the THIRD option - CANCEL by default.

Why? Well, if I didn't quickly recall what I'd done to "that form" (or what have you), then I'd better danged well CHECK on what changes it might be wanting to save before deciding. THIS is what that Cancel button is FOR, after all.

The underlying reason for this is: the change could be right and good, it could be temp code I forgot to erase, or it could be a "bogus change" (for lack of a better term). I term those as Bogus changes because I may darned well have done them accidentally, or by just plain clicking in the access UI design mode of a form or report sloppily (or fat-fingering keys while in the VBA code editor). After all, just grab a control on a form, and hold that button juuust a skosh too long, and dangit if you didn't drag that control over one grid-stop (in the wrong way, of course). There are just so many ways for a developer to screw stuff up by mistake while doing other things deliberately sometimes.

So, call it Laziness Defense if you want, but I hit Cancel when that Save dialog catches me unawares, and I darned well FIND OUT what may be "wrong now".

I yada-yada'ed the bisque

After reading Mark's post, I went back and re-read my article.  It turns out that I had left out the most important reason why I always choose [Yes].  In that original article, this was the extent of my explanation for my choice:

After all, the worst case scenario is that I just roll back my changes and get back to where I would have been if I clicked [No].

My limited explanation makes my current behavior sound much more cavalier than it actually is.  Mark pushed back on my explanation with this line in particular, with which I completely agree:

Well, if I didn't quickly recall what I'd done to "that form" (or what have you), then I'd better danged well CHECK on what changes it might be wanting to save before deciding.

Identifying changes

When I read Mark's sentence, I immediately thought, "Exactly, that's why I always say [Yes].  Because then it's easy to figure out what changes I actually made."

Those of you who use version control in Access are probably nodding along right now, while the rest of you have your heads cocked to the side staring at your computer screen like a confused German shepherd.  

How exactly does the act of saving your changes make it easier to identify the change you made?

Photo by Yaroslava Eff on Unsplash

It's all about the Diff

The biggest reason I save my changes instead of clicking [Cancel] or [No] is because version control makes it so much easier to figure out what changed.

For example, let's say I've made some changes to a form.  I mean, I don't remember changing the form, but Access asked me if I wanted to save my changes, so I must have changed something.  If I click [Cancel], my only option is to start reading through the code, looking at the controls on the form, and hoping that something sparks my memory as to what I changed.

But what if I added–and then removed–a temporary line of debugging code?  I could look for hours and never find what changed...because the form is exactly the same as when I started!  But Access doesn't know that.  As soon as I started typing in the form's code-behind, Access marked the form as dirty.  

Even if all I did was type a single space in the code editor window and then immediately press [Ctrl] + [Z] to undo that change, Access will still ask me if I want to save my changes to the form.

Imagine the frustration of trying to track down a change that you've already undone.  The task is literally impossible, since the change itself no longer exists.  

The only way to know for sure what changed is to directly compare it to what was there before you started editing the form.  And that's where version control comes in.

With version control, all I have to do is export my Access objects to text files, and then compare the new version of my form to the latest revision from my repository.  The Diff format does the hard part for me.

Here's what it looks like with TortoiseHg:

Oops, I shouldn't have saved that

This is great if you saved something you wanted to save.  But what if you don't want to keep the changes you saved?  

I'll cover that situation in my next article.