Thursday, May 28, 2020

Writing useful commit comments

Some thoughts on writing useful [concise, descriptive, contextual] commit comments. Applies to all SCM systems (Git, Subversion, etc.)

A properly formed Git commit subject line should always be able to complete the following sentence:

  • If applied, this commit will your subject line here
For example:
  • If applied, this commit will refactor subsystem X for readability
  • If applied, this commit will update getting started documentation
  • If applied, this commit will remove deprecated methods
  • If applied, this commit will release version 1.0.0
  • If applied, this commit will merge pull request #123 from user/branch
Chris Beam

Thursday, May 14, 2020

Don't name ANYTHING AUX, or NUL, or...

Further to my earlier post, I discovered 'aux' is not just a bad choice for folder names, it's bad for ANY file name on Windows!

Apparently back in the Dark Ages (1974 or so) when Bill Gates invented computers, the Interwebs and everything else digital, AUX, NUL, COM3, etc. were deemed names reserved for the OS, "magical files" if you will. That decision lives on through backward-compatibility (c'mon, 1974?! CP/M?! DOS?!?!?).

While working on my project, MS Visual Studio Code happily agreed to let me name a file"aux.yaml". Even though this ominous warning appeared, it let me continue once I appended "yaml" to the name:

 Everything went fine until I tried to add the file to the project's working copy in Subversion. For some reason, no matter how many times I pressed "Add..." in TortoiseSVN, the file refused to appear in the commit list, and failed to adopt its stroppy little blue plus sign in Windows Explorer.

Hmm, let's open it with Notepad++ to make sure the file is OK - nope, Notepad++ complained bitterly about the file when I tried to open it:

So at this point I figure the file was somehow corrupted by my attempts to add it or move it around in the Subversion working copy, let's just nuke it and start over:

OK this is definitely weird.

A few minutes googling produced the answer: open an admin command prompt and delete or rename the file. The command ren \\.\C:\path\to\file\aux.yaml auxiliary.yaml put everything right again - TortoiseSVN happily added the file, Notepad++ opened it with nary a whimper, and Visual Studio Code - well, let's just say it has it's own opinion on file names.


How a 1974 bug still bites Win10 and Azure users

Monday, May 11, 2020

Windows error naming folder 'aux' - wat?!

Windows complained, unjustly I thought, when I tried to name a folder 'aux'. Turns out this is one of a number of restricted MSDOS device files:

LST (only in 86-DOS and DOS 1.xx)
KEYBD$, SCREEN$ (only in multitasking MS-DOS 4.0)
$IDLE$ (only in Concurrent DOS 386, Multiuser DOS and DR DOS 5.0 and higher)
CONFIG$ (only in MS-DOS 7.0-8.0)

Thursday, September 19, 2019

How to Get a Good Old Command Prompt from Windows Explorer in the latest Windows 10

Remember the ol' shift-click in Windows Explorer trick to open a command prompt from a folder?

Windows 10 since version 1803 (?) helpfully offers to open a Powershell prompt instead:

Which is great, if I want Powershell, which I don't. Apparently there's no way to revert or override this helpful 'feature', so I went around the side door - I shift-clicked to open Powershell, then typed "cmd" at the Powershell prompt, et voila, I get a good old command prompt in the folder:

Thursday, July 18, 2019

Neil Armstrong's first step happened on my 10th Birthday! Or did it?

Did Neil Armstrong's historic first step on the moon land on my 10th birthday? Let's see. NASA published a detailed timeline of the Apollo 11 mission, and with a little help from date/time conversion websites, and a confirmation that California did indeed observe PDT in 1969, I constructed this timeline of the highlights:

Apollo 11 Timeline

Event       PDT (UTC-7)     EDT (UTC-4)     UTC (GMT)       SAST (UTC+2)
                                                            No DST
----------- --------------- --------------- --------------- --------------
Liftoff     6:32 am          9:32 am        1:32 pm          3:32 pm
                                            Wed 16 July

Landing     1:17 pm         4:17 pm         8:17 pm         10:17 pm
                                            Sun 20 July

First       8:56 pm        11:56 pm    |    2:56 am          4:56 am
Step        Sun 20 July                |    Mon 21 July

My 10th     10:35 pm
Birthday    Mon 21 July

Lunar       10:54 am        1:54 pm         5:54 pm          7:54 pm
Ascent                                      Mon 21 July

Splashdown   9:21 am       12:51 pm         4:51 pm          6:51 pm
                                            Thu 24 July
I have a recollection of watching the landing on (black and white) TV, then looking out the window at the sky, thinking, "Wow, they are up there right now!". I don't recall if the Moon was visible during the day at that time.

Well, sadly, as I was living in Petaluma, California at the time, Neil's boot hit the moondust at 8:56 pm PDT on Sunday, July 20th, the day before my 10th birthday.

For a certain someone in Cape Town, however, it happened very early on her 10th birthday!

Wednesday, May 1, 2019

Perl - get the script path

# C:\Foo\Bar\

use strict;
use warnings;

use FindBin qw($Bin);

print "My script lives in $Bin\n"; # My script lives in C:/Foo/Bar

Note that there is no trailing slash, and Windows back-slashes '\' are converted to forward slashes '/'

Wednesday, April 3, 2019

How to Roll Back (revert) an SVN commit

Crap. My last commit in Subversion broke Jenkins. How do I undo it?

Sometimes TortoiseSVN gives us too much of a good thing. There are several options with similar names for "reverting" and "updating" files in Subversion, and I can never keep them straight, thus another post that tries to sum up the options and their effects.

First, just a simple "undo":

Revert a single file:
  1. Right-Click -> TortoiseSVN -> Show log
  2. Find the revision/changeset you want to rollback to (i.e. the revision just before the change you want to remove)
  3. Right-click on the single file in the list of files -> Revert to this Revision
Revert the entire changeset:
  1. Right-Click -> TortoiseSVN -> Show log. 
  2. Find the revision/changeset you want to rollback to
  3. Right-click on that revision -> Revert to this Revision
(Paraphrased from eduncan911's lucid instructions in this post on Stack Overflow)

Wait a minute. The context menu in TortoiseSVN (1.9.7.x) shows three similar commands when selecting a revision in the list:
  1. Update item to revision
  2. Revert to this revision
  3. Revert changes from this revision
and just the last one, "Revert changes from this revision," when selecting an item in the list of files.


Here's what each "Revert" option does, according to JB Nizet again on Stack Overflow:
Let's say you have these N successive commits: 1, 2, 3 and 4.
If you select the commit 2 and choose "Revert to this revision", your working copy will contain the changes brought by commits 1 and 2. Commits 3 and 4 will be "canceled".
If you select the commit 2 and choose "Revert changes from this revision", your working copy will contain the changes brought by commits 1, 3 and 4. Commit 2 will be "canceled", or rather, played in reverse on the top of commit 4: if a line was added, it will be removed. If a line was removed, it will be re-added.
(Emphasis and spelling corrections are mine)

So it would follow that either option has the same effect when undoing just the last commit on a file.

How about "Update item to revision" vs "Revert to this revision"? Here's Peter Parker's explanation on Stack Overflow:
Update to revision will only update files of your working copy to your chosen revision. But you cannot continue to work on this revision, as SVN will complain that your working copy is out of date.
revert to this revision will undo all changes in your working copy which were made after the selected revision (in your example rev. 96,97,98,99,100) Your working copy is now in modified state.
The file content of both scenarios is same, however in first case, you have an unmodified working copy and you cannot commit your changes (as your working copy is not pointing to HEAD rev 100), in second case you have a modified working copy pointing to head and you can continue to work and commit
(spelling and punctuation corrections are mine)