Dieter Reiter has attacked the Limux project from day one he was in office, starting to spread FUD like his inability to access his mobile mail was due to Limux flaws instead of workflow issues. His head of IT publicly denied Reiter's claims and refuted them. Mr. Reiter has "outed" himself as a Microsoft fan in the past (before he became mayor) and was personally involved in moving Microsoft Germany's headquarters from the Munich suburb to the city of Munich itself. So this is more of a personal/political issue. Munich's IT staff still thinks Limux is a good solution and luckily there is opposition to Reiters FUD in the town hall. Going back to Microsoft would be very costly but now that Microsoft has its HQ in Munich, I'm pretty sure the lobbying has taken up steam and there's going to be "deals benefiting both sides" here.

Over the years, I've worked with about 20 different languages. I learned a lot of them purely out of interest. Even if you won't need it for any "serious" or paying work, it can be useful to learn a new language that is different from the languages you know. For example, if you know C# you won't learn that much by working with Java; they're too similar. By contrast, if you try learning a language like Haskell or Go instead you'll get introduced to new ways of thinking.

In almost all languages, there are things you can do easily or "naturally" in it. These language (and framework) features usually influence how you would design a program in that language. And it's these concepts that are worth learning. For example, when I learned Ruby and later Haskell, I learned how powerful concepts like map/select or working with closures are.

This knowledge then transferred to the languages I usually work with; my designs in my "traditional" languages changed because of the things I learned while working with other languages.

So even if the new language is not "one the rise" it might pay off by indirectly improving your skills in the languages that you do get paid for.

Dang, me using the incorrect case of the "v" suddenly destroyed several years of experience? Oh gosh, and I thought actually following the mailing-list for several years since the betas and reading about how and why those people designed the tool would give me some understanding about it, but you're right: spelling is way more important.

I'd love to see you explain all this to an average office lady :-)

I've worked on a SubVersion project for several years where the smallest useful checkout was 5GB (it was an in-house Linux distribution I've built and maintained). On a local network, SubVersion works pretty well for these things but you're right, I wouldn't want to do this over a poor Internet connection. It's pretty space efficient with binary files and handles things like copies and renames very well, so if you need to deal with them a lot then SubVersion is a good choice. Git and SubVersion work very differently, each have features the other doesn't have, by design. Believe it or not, SubVersion was also *designed* for large projects, but different use-cases. I really, really wouldn't want to maintain my distribution with Git. Now that I'm a "normal" developer again, we're using Mercurial and Git since they're better suited for these tasks, handling source/text files with lots of branching and merging.

Have you ever split a large project into several components stored in different repositories and tried to keep them in a consistent state? Like, trying to rebuild a version exactly as it was one year ago because a customer needs a very specific fix for that version? I've come to learn that especially with huge projects it can be a very good idea to have everything in one repository.

With SubVersion, you can check out subtrees instead of the whole repository (even non-recursively, so you can check out a directory "in the middle"). That's something that Git or Mercurial can't do by design; IIRC it's because the always-complete-repository approach makes merging and other tasks much, much easier. In your SVN working copy, only the data of commit you've checked out are stored. For everything else SVN needs to contact the server which depending on the requirements and workflow, is either a good or bad thing. On the other hand, Git and Mercurial do have the complete history locally which allows them to perform a lot of tasks without contacting a server that SubVersion could not do (simple example: get log history of a file).

But it's actually besides the point: all of these things won't matter to an office user. Ease-of-use and chances-to-screw-up do.

Now you've got into rant-mode, sorry. I really hope non-technical people are never forced to actually type in commands but use a GUI instead, no matter which VCS they use. But especially with Git. I think Git is a very powerful tool and have come to like it for its features, but I still hate it for its commands and what I feel are inconsistencies and "fuck how other VCS are naming it, we use something different".

For example, discard changes on a single file: "git reset foo.bar". Discard changes on all files: "git checkout -- .". WTF? Just a few days ago, I wanted Git to give me the diff of specific commit, the equivalent to "svn diff -c revision" or "hg diff -c revision". In git? "git diff revision^ revision" or "git diff revision^!" (which I overread when I was reading the man page and needed to look it up on Ye Olde Interweb). Or "git diff-tree -p revision" or "git whatchanged -m -n 1 -p revision" since why not? And "git add" both adds a new file to the repository but also picks a modified file to be included in the next commit (but only the parts that have not changed between add and commit. The add behaviour does make sense when you think "from the inside" of the VCS, but I was confused at first and I'm a technical guy. Normal people will have trouble with this stuff. Seriously, I've been using various VCS in last two decades and still am doing a lot in the shell, especially VCS stuff since I feel to be more in control this way. But Git is the first VCS that I use almost exclusively in a GUI because it's CLI is too cumbersome.

I've been using SubVersion since it was in beta and have used it at work and in private in multi-gigabyte projects. SubVersion was always rock-solid for us, and it's handling binary files very well (which was the prime reason we decided to switch use SVN back then in about 2003). Git is an excellent tool for us developers, but I feel it's way too complicated for non-technical people who don't need these bells and whistles.

As a first language? That's like giving a kid a Hayabusa instead of a bike with learning wheels.

That's exactly how I started as well. The manuals I had were in english (plus DOS; that's how I picked up basic english) but we had books in our library that were in German. So not knowing english doesn't stop you, but I guess it would've been easier/nicer if I would've been able to start in my native tongue.

Learning a whole language first isn't much fun. Also, lots of people I know (me included) learned programming first, then (through programming) english. I started with GW-BASIC at age of 7 and almost everything was in english: the programs I had, even the manuals. I picked up basic english from this (after some trial and error you understand what certain words or phrases mean; I was pretty surprised when I learned at school that these words are pronounced totally differently than I imagined ;-)

I even knew a pretty good programmer who still does not speak english. He couldn't ask for directions if he'd get lost. Yet he manages to do hold up as a professional. Couldn't believe it at first, but it shows that knowing english does help when developing but it's not strictly necessary. The good thing about programming is that the syntax rules are so much more strict and easier to understand than natural language.