Then came the DCVS.

Early discovery

I first learned about Mercurial. I was impressed by its great merging and branches abilities, more than the whole “distributed” concept, however I found it a bit tricky to install and make it work in Windows, especially with TortoiseHg, which was definitly not yet as good as its older brother, TortoiseSVN. So I didn’t look further, and stuck with SVN for the time being.

A few years later

I’m now working in an environment where rapid website release cycles mean that a lot of developments/commits make it directly to production, the production environment being directly based on the current trunk, probably a wrong approach, but most developers in the team don’t care about branches.
This means that if someone is working on a feature that hasn’t been completed and spans several commits on the trunk, any urgent bugfix will cause these features to go online, and inevitably cause bugs on the production website.

The obvious solution to this problem is feature branches, branches that only live for as long as the feature is not complete, and get reintegrated into the trunk when functional and tested.
However, in SVN, every branch is server-side, which means that the central repository might become really encumbered with trash in the /branches directory, unless each developer deletes such a branch when done with it. Guess what ? In practice, a lot of orphean branches remain, and noone cares about deleting them.
Of course, this has an interest because SVN also works as a code backup platform, so at the end of the day, each developer should put his code on the well-protected server, instead of keeping it on their potentially dead-the-next-day desktop computer.
Also consider the fact that developers can work from home as well as from the office, and potentially need their code from anywhere.

SVN has also another flow, it’s really getting slow when working on large codebase, especially with binary files like images, quite common in websites.
This is caused by the fact that everything happens between the client and the server, even getting file or repository-wide history. Trying to work out a problematic trail of changes is basically impossible if the internet connection is down for some reason.

Here comes a new challenger

That’s why I got very interested when I tried Git, which I had been following since its introduction by Linus Torvald, after the famous issue with Bitkeeper.
Git’s Windows support has evolved quite a bit since the early days, and I must say that TortoiseGit (a TortoiseSVN clone) has become a quite good piece of software, allowing people to more easily bypass the initial steep learning curve of the many many git commands and options, by using a simple yet potent and familiar UI.

Git solves practically every issue I have encountered so far, especially about branches. Feature branches are a core part of Git’s workflow, and they’re freaking fast.
It also makes working locally very practical, as apart from the initial cloning, and eventual pull/pushes, everything is done on the client side.
And at least branches and tags are properly implemented without feeling “half-baked”.

Now you might certainly ask me: “how can it be used in a server-is-the-backup environment if all is done in a distributed way ?
Very simply of course. As long as a developer has access to a machine via SSH and that has git installed, saving your work is just a matter of creating a bare repository in your account, and add it locally as a remote into which you can push and pull at will, without ever needing to communicate with the “central” repository.

Goodbye, really ?

At work, no, we’re not quite ready for the switch yet, but it will come, eventually.

I’m talking about flvmeta, instead.

When I decided to host flvmeta publicly back in 2007, I decided to choose Google Code project hosting, because of its simplicity, and its support of SVN. It’s been a good choice, and has worked flawlessly since then, with an active community, bug reports, and a now established codebase (says ohloh.net).

These days, I’m working on the trunk, to complete the 1.1 release of the software. It’s much more advanced than the 1.0.x branch, and given its good stability, I encourage people to use it instead, even though some planned features are still being developed.
So there’s no format release yet, and people are encouraged to use the latest trunk revision.

This approach gives me, the main developer, a moral obligation: the trunk must NOT be broken. I’ve been very tempted to use feature branches to work around that issue, and so I created a repository at Github based on a conversion from the flvmeta SVN.
I must admit that I like Github a lot, and so I decided to maintain both the SVN and Git repository in parallel, opting not to use git-svn facilities, just to compare Git to SVN for daily tasks.

After a while I’ve started to wonder about closing the google code project in favour to Github entirely, because this double-repository thing is just an annoyance, and using feature branches in the Git version adds the risk to desync it from the SVN repository, which could confuse users.

And then, yes, they did it, Google added support for Git in Google Code ! So I uploaded my local flvmeta repository to Google Code, converted the Wiki SVN to Git, and that’s all there was to it. Now Github and Google Code are both mirrors for my local repository, and keeping them in sync is just a matter of pushing correctly.

Last words

I’m now a happy gitter, I will not come back to SVN for flvmeta. I just need to fix a few things in the build scripts, because I relied on SVN revision numbers to tag the executables during compilation, if just to make support easier by having people telling me the exact revision of the program they’re using.
It will just be a matter of using git hashes instead, there’s a handy command that I can use for that: git rev-parse --short HEAD, or even git describe --always.

The only thing that I don’t like with Google’s support of Git is that they decided to stick to the most used and abused protocol ever, HTTP, instead of ssh: or git:, therefore forcing me to enter my password for every interaction with their servers, since TortoiseGit won’t let me save authentification data.
I really prefer how Github handles authentication, by using cryptographic key pairs, that can be revoked individually, so if a developer machine is ever compromised, risks can be mitigated.

Snapshots can be downloaded on the Google Code project page at: http://code.google.com/p/flvmeta/downloads/list

A lot of new features have been added, here is an exhaustive list:

A few things are still missing for the next stable release, for example some proper user documentation, now that a complete set of command line options are available, as well as the implementation of the check command.

Everyone is welcome to test the software and report bugs on the issue tracker.

I’m also still pondering the benefits of using gettext in order to fully internationalize the output of the program. On one hand, there are many people who don’t speak english, and adding the potential to reach a wider audience is tempting. It is also a must-have in order to be featured in distros like Debian.

On the other hand, I still have issues with building flvmeta with gettext enabled. First of all the cmake/windows combination would be kind of experimental at best, and using autotools, I still need to fully understand which files must and must not be added to the repository.
There’s also the question of performance, since flvmeta is mostly used as an automated tool for update purpose. Dynamically loading strings in that setting is kind of pointless since speed and memory can be affected and there’s noone to ever read those messages anyways.

After version 1.1, which is transitional in the sense that it really represents the maturation of flvmeta into a real CLI tool, a 1.2 version will be in development.

Features expected for 1.2 include:

To add a quick follow-up to my previous post, I might add that… no, FLV is not quite dead yet, since H.264 streams in FLV containers are working quite well in the Flash Player, and major sites have adopted that combination.
I think we also might even expect support for On2 VP8 in FLV files before the end of the year. If Google really open-sources its code, alternative flash implementations will certainly jump the wagon before maybe even Adobe.
Of course, due to Adobe being a major On2 licensee, as well as thanks to the rather good relationship between them and Google, the official Flash Player might support this codec fast enough for it to become a viable alternative to the increasingly controversial H.264.