Let’s start with a bottom line: if you’re a JIRA user, please take a few seconds to vote for the ‘JIRA Pre-Upgrade check’ suggestion
Now for the whole story:
Recently we upgraded one of our JIRA instances. It all seems well at first and then small problems started to pile up.
After contacting Atlassian support, it turns out we should have upgraded our database server (Oracle in this case) before the upgrade (“it’s in the documentation!”). We didn’t, so some data upgrade tasks silently failed, without any notification during or after the upgrade process.
I was surprised. As a long-time installation developer I learned one thing: users don’t read the documentation until they have problems. They certainly don’t read installation guides; at most they skim through the release notes. That’s why every installation I create includes some basic validations regarding the environment (e.g. OS, database, Java…).
So, I suggested Atlassian to add this kind of checks to their own installer and they immediately agreed. All that’s left is to gather enough votes so it would go into their suggestion review process. Appreciate your help!
I recently encountered an elusive bug, which eventually I tracked down to the fact that environment variables are not replaced in a certain string even though it is set by calling os.path.expandvars(original string).
Turns out, the problem is that expandvars() doesn’t expand variables who are enclosed within a string literal. I couldn’t find it documented anywhere but facts are, this is the case.
>>> import os
>>> os.environ['VAR1'] = 'Value1'
>>> s1 = "this is '%VAR1%'"
"this is '%VAR1%'"
>>> s2 = "this is %VAR1%"
'this is Value1'
It may be a good idea in some cases, but for me it was quite an annoyance.
So, how to overcome this?
Microsoft is all about Git in the last couple of years, and a few days ago they announced an exciting new feature they are working on that should really take Git to the enterprise level.
The GVFS (Git Virtual File System) is a way to make Git “believe” that it is working with the entire repository clone, while in reality all files reside on the server, and are only downloaded the first time something tries to access them.
This means that even for very large repos, clone time is next to nothing, and commands like git status can take a few seconds instead of several minutes. The only payment is the time it takes to run a build, or to open a solution, for the first time.
Somehow I can’t shake the feeling that it was inspired by ClearCase MVFS (Multi-Version File System), which at the time was an excellent way of working against large repositories without spending hours of copying data to the local machine. Of course MVFS has a whole set of problems, but the basic idea of ‘download content only when you actually need it’ was innovative at the time, and apparently has its uses today as well.
I’ll keep a close watch on how GVFS is shaping up in the coming months. It can be a real life saver for companies like the one I work for, which are struggling with the idea of switching to Git, considering a 150 GB repository and over 200,000 files in a typical workspace.