I use Mercurial, but only selectively on some projects, and not on others.? My backup process is completely separate, and my repo's are local on my machine (also get backed-up), because I'm a solo dev.? If I had a team, I would have a different solution for repo location/storage.
I chose Mercurial, only because at the time, TortoiseHg provided a very nice, intuitive GUI to use.? It supported multiple local repos, and was easy enough to learn and get started with and was intuitive.? I believe GIT is all these things now days too, but at the time I was making the choice, all the info I had heard about Git was that all the GUI interfaces sucked (or were commercial paid software or rent-ware), and I wasn't sure if it supported local repo's, and everytime I read about using GIT on the internet, it was always a group of people that use command line, argue over the proper way to GIT something from an online repo, and complicated merge/pull/diff/push request dances.? To be fair, I think Mercurial and Git are closer than I realized, but the Git users like more to pretend to be more hardcore.? Nomenclature of the functions might be the biggest difference between them, but I could be wrong.? The other reason I chose Mercurial at the time, was you can get a free personal bitbucket account for private repos if I wanted to go cloud based at some point, but at the time, free Github repo's were public only, and you had to pay for private repositories.? I wasn't sure if I wanted cloud based repo's, but I wanted to option to try them without having to subscribe.? Now that I have repo's in Hg, and I know how it works and expected behaviour, I just haven't put in the time to convert or move to Git, I don't think the advantage would be worth the time/effort.
As far as using it in production, do tests yourself, but it works for snapshot points, revisions, rolling back easily, and all that simple stuff that you mentioned.? Except for maybe S# files or S+ files, do not expect to be able to do merges or diff's successfully or you will run into issues.? I found it works great when I use it for AMX projects, because those all consist of C like files for the project, the project file itself is text based, and so there is greater use of features.
But the big problem, no matter what control systems you program (Crestron, AMX, Extron), is that they all use a high percentage of Binary files, as you mentioned, like Touchpanel files, IR files, compiled files/modules, project containers, DSP files and configuration backup files.? These files can be checked in to revision control, and rolled back/forward, but they don't get saved in an incremental way well.? From what I can tell, the entire new file is checked in on many of these file types that are binary types (not text based).? This means that your repository for a particular project can grow EXPONENTIALLY huge depending on how many of these binary files you have, their size, and how often you are doing changes/check-in's on them.? So if your .VTP file is 30MB, and you do 10 check-ins, that stores somewhere around 300MB in your repo (not exact, just estimate).? It doesn't diff the files well from what I understand.? I'm not sure if Git works better in this regard, but from what I've read, I don't think it does, or does much better at least.
This is the biggest drawback IMO, just because of the kind of files we are dealing with aren't as friendly with GIT/Hg as web and other programming languages in many cases.? But it works none the less.? And it's not any worse than just keeping copies with revisioned file names, as that too takes just as much space.
The other issue, that I've ran into, that I'm not sure the best way to solve this, is in knowing what the latest version that was loaded/deployed onsite later, or when dealing with other parties, like integrators or end-users.? Because your files names are not being revisioned, there isn't an easy way to tell if the file that is loaded into that processor has that latest patch that you just worked on, or was the version prior to that, or is several versions prior...? Normally the file name and compiled-on date/time in toolbox is what I go off, and that's not as helpful if the filenames don't change.? Integrator's get confused on this as well, when they ask for a patch for some issue they found, and you send them a new file, and it's the same name as the last file they had.? Not everyone is familiar with how Revision control works, and therefore think you don't have a revision control system in place when the filenames don't change and have a new rev number in the name.
