Code · Work

EasyMercurial v1.4

Today’s second post about a software release will be a bit less detailed than the first.

I’ve just coordinated a new release of EasyMercurial, a cross-platform user interface for version control software that was previously updated in February 2013. It looks a bit like this.

Screenshot from 2018-12-20 18-55-36

EasyMercurial was written with a bit of academic funding from the SoundSoftware project, which ran from 2010 to 2014. The idea was to make something as simple as possible to teach and understand, and we believed that the Mercurial version-control system was the simplest and safest to learn so we should base it on that. The concurrent rise of Github, and resulting dominance of Git as the version control software that everyone must learn, took the wind out of its sails. We eventually tacitly accepted that the v1.3 release made in 2013 was “finished”, and abandoned the proposed feature roadmap. (It’s open source, so if someone else wanted to maintain it, they could.)

EasyMercurial has continued to be a nice piece of software to use, and I use it myself on many projects, so when a recent change in the protocol support at the world’s biggest public Mercurial hosting site, Bitbucket, broke the Windows version of EasyMercurial 1.3, I didn’t mind having an excuse to update it. So now we have version 1.4.

This release doesn’t change a great deal. It updates the code to use the Qt5 toolkit and improves support for hi-dpi displays. I’ve dragged the packaging process up-to-date and re-packaged using current Qt, Mercurial (where bundled), and KDiff3 diff-merge code.

Mercurial usage itself has moved on in most quarters since EasyMercurial was conceived. EasyMercurial assumes that you’ll be using named branches for branching development, but these days using bookmarks for lightweight branching (more akin to Git branching) is more popular — EasyMercurial shows bookmarks but can’t do anything useful with them. Other features of modern Mercurial that could have been very helpful in a simple application like this, such as phases, are not supported at all.

Anyway: EasyMercurial v1.4. Free for Windows, Linux, and macOS. Get it here.


SoundSoftware tutorial at AES 53

I’ll be co-presenting the first tutorial session at the Audio Engineering Society 53rd Conference on Semantic Audio, this weekend.

(It’s the society’s 53rd Conference, and it happens to be about semantic audio. It’s not their 53rd conference about semantic audio. In fact it’s their second: that was also the theme of the AES 42nd Conference in 2011.

What is semantic audio? Good question, glad you asked. I believe it refers to extraction or estimation of any semantic material from audio, including speech recognition and music information retrieval.)

My tutorial, for the SoundSoftware project, is about developing better and more reliable software during research work. That’s a very deep subject, so at best we’ll barely hint at a few techniques during one programming exercise:

  • making readable experimental code using the IPython Notebook, and sharing code for review with colleagues and supervisors;
  • using version control software to manage revisions and escape disaster;
  • modularising and testing any code that can be used in more than one experiment;
  • packaging, publishing, and licensing code;
  • and the motivations for doing the above.

We presented a session at the Digital Audio Effects (DAFx) conference in 2012 which covered much of this material in presentation style, and a tutorial at the International Society for Music Information Retrieval (ISMIR) in 2012 which featured a “live” example of test-driven development in research software. You can find videos and slides from those tutorials here. The theme of this one is similar, and I’ll be reusing some code from the ISMIR tutorial, but I hope we can make this one a bit more hands-on.


Code · Gits and Hubs · Work

The extraordinary success of git(hub)

The previous post, How I developed my git aversion, talked about things that happened in the middle of 2007.

That was nearly a year before the launch of github, which launched publicly in April 2008. I know that because I just looked it up. I’m not sure I would have believed it otherwise: git without github seems like an alien idea.

Still, it must be true that github didn’t exist then, because it would have solved the two problems that I had with git. It answers the question of where to push to, when you’re using a random collection of computers that aren’t always on; and it provides the community of people you can ask questions of when you find yourself baffled.

And that community is? All developers. Or at least, all those who ever work in the open.

The amazing success of github—and it is facilitated by the architecture of git, if not the syntax of its tools—is to produce a public use of version control software that is completely out of proportion to the number of developers who ever cared about it before.

That’s because github has so many users who are not classic “software developers”, but I suspect that it’s also because so many software developers would never otherwise use version control at all. I can’t believe that very many of github’s current users are there for the version control. They’re there for lightweight and easy code sharing. Version control is a happy accident, a side-effect of using this social site for your code.

I still don’t really use github myself, partly because I don’t really use git and partly because of a social network antipathy. (I don’t use Facebook or Google+ either.) But it’s a truly extraordinary thing that they’ve done.

Code · Gits and Hubs · Work

How I developed my git aversion

In the summer of 2007, I switched some of my personal coding projects from the Subversion version control system to git.

Git was especially appealing because the network of computers I regularly worked on was quite flat. I did some work on laptops and some on desktops at home and in the office, but for projects like these I didn’t have an always-on central server that I could rely on pushing to, as one really needs to have with Subversion.

So even though I was working alone, I was eager for a distributed, peer-to-peer process: commit, commit, commit on one machine; push to the other machine or a temporary staging post online; pick up later when I’m at the keyboard of the other machine.

Git wasn’t the first distributed version control system I’d had installed—that would be darcs—but it was the first that looked like it might have a popular future, and the first one I was excited about being able to use.

My excitement lasted about a week, and then I lost some code.

I lost it quite hard: I knew I’d written it, I knew I’d committed it, and I knew I’d pushed it somewhere other than the machine I’d written it on, although I couldn’t remember which machine that had originally been. But I couldn’t find it anywhere.

It wasn’t visible on the machine I’d pushed it to, and I couldn’t find it on any of the machines I might have pushed from. In fact, I never did find it. I’d managed to get my code enfolded into the system so that I could no longer get back to where I’d left it. I didn’t know anyone else who used git at the time, to ask for help. I’d fallen for a program that was cleverer than me and that wasn’t afraid to show it.

And as a long-time user of centralised version control systems, the idea of losing code after you checked it in was really a bit shocking. That shouldn’t ever happen, no matter how dumb you are.

So I went back to Subversion. Technically-better is not always better.

The reason for my confusion was that in my excitement I’d been imagining I could freely do peer-to-peer pushes and end up with the same repository state at both ends—something any fool could tell you is just not the way it works. (I probably lost the code by doing a push to a bare repository, something that is now harder to do by accident.)

As it happens, though, the way I had imagined it would work… is the way it works with Mercurial.

So when I found Mercurial I became happy again, and I’ve been happily using that ever since. Of course git has become so popular that you can’t really avoid it, and I know it well enough now that I wouldn’t make those mistakes again. Still, how much happier to use a system that actually does work the way you expect it to.


New 1.2 release of EasyMercurial

At the SoundSoftware project we’ve just released a new version of EasyMercurial, our user interface for the Mercurial version control system.

This release has one change that I think is quite interesting—we’ve removed one of the five big buttons that used to occupy the main toolbar. It turned out that the meaning of the “Refresh” button wasn’t anywhere near as clear to users as we had foolishly imagined it to be during development. Our article about the release explains in a bit more detail what the problem is and what we did about it.

This is one advantage of having a constantly-shifting population of fairly autonomous users around you, as you do in a university research lab. Although our users don’t always have the time to test much, we do get a fairly broad range of use cases being tested. Working out how to act on the feedback we get is the hard bit!

(One exception, though, is that we have relatively few in-house users running EasyMercurial on Windows. So if you’re a Windows user, your feedback is especially valuable.)