I've been using git (and GitHub) at my day job for a couple years now, and I'm still not sure I'm sold on it over Subversion.

In the past, version control was something that existed but you never had to think about. When you got to a good place, you'd hit the big red Save Button and up your code would go. Once in a blue moon you'd step on somebody's changes and have to do a quick merge. No big deal.

Now with Git, version control is part of the workflow. It's never far from your mind. You're creating branches before writing code (versus creating branches three times a year when you needed them). You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you.

I'm sure there are times where Git has actually made things easier, but most of the time it's just one extra thing taking up my attention.

It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

> In the past, version control was something that existed but you never had to think about.

I think this statement highlights the fact that there are really two camps of developers when it comes to version control software. The difference between the two is what they consider to be the primary artefact that they are working on.

One camp considers the primary artefact to be the source tree that they have in front of them. The other camp thinks that the history of that tree over time, as represented in the version control system, is the most important and valuable thing.

Where things get rough is when members of the 'source tree' camp have version control imposed on them, usually by some corporate policy change. For them, the version control system is just like a backup. Commit messages are perceived as valueless as the developer never expects to see them again, so quite often they will be blank. Any change to the workflow that gets between the developer and making a change to their source file is a hindrance.

I would not recommend that an organisation with developers who are primarily 'source tree'ers try to adopt git. As the parent says, it requires too much knowledge of the tool, change to workflow, and, above all, commitment to having the git repository represent a detailed history of the development process. For them, a simpler tool the stays out of the way is probably more suitable.

Thank you! Your post explains what I've been seeing at the day job.

We switched from a Subversion-like proprietary VCS to git about six months ago.

We needed to because the proprietary thing was a stupid waste of money (it was basically equivalent to Subversion in capabilities), and because its ability to do the sort of branching we found ourselves in need of was severely limited. So we switched to git.

We've had more than a little culture shock since then - and basically it's because we work in source-tree mode, and history is something you delve into only when you have to. In fact, when we moved to the new system (git on Github) we didn't even port history - we started the Github repos with a historyless copy of the source, and left the old stuff in the old system should anyone need to look at it. Github basically serves the role of the central repo in the old system.

We would never go back - git centred on Github is a vast improvement on the old system - but it's a bit too fully-featured for what we want from it, and has the problem you describe where we have to think too much about the tool's view of things.

> change to workflow

The only change to my workflow coming from a little bit of SVN and a whole ton of CVS was pull and push. Other than that, you can work exactly as you did in CVS and SVN if you want to. Sure the commands are a bit different, but the workflow can be the same.

Only if you keep a clear picture in your head of the tool's view of your repo - in a manner that CVS/Svn does not require you to. Otherwise you are pretty much certain to shoot yourself in the foot, repeatedly. Source: watching our devs do precisely this.

That is a useful distinction. However it is possible to hold a middle view, i.e that while the "current source tree" is most important - it is what you build and deploy, what you are most likely to base future work upon; the history is also an important artefact, and more than just a backup.

I like a good code history, but not at the expense of good current code!

What the heck? I couldn't disagree more.

You don't have to create a branch before you write some code. Write the code, and if you think it should go on a different branch, type "git checkout -b 'branchname'". But if you don't want to, you don't have to! work on master for all anyone cares. Branches just help you! IF they are too hard, don't use them.

Branches were so problematic in subversion that nobody did them. In git, if you want to, then do it.

If you accidently check in something, just "git rm" it. You have this extra staging area.

If you are finding there is something problematic with your workflow, take the time to look up how to do it, and you'll find that the fix is a command away. You should never be copying/pasting stuff back into your IDE. If you are, you're doing it wrong.

http://gitref.org/ is pretty good if you get stuck.

I agree with you, and would like to add to it. The parent said git gets in the way ... I couldn't disagree more with that. More than any other version control software, git stays out of my way and my workflow until I need it. Rename a file? No big deal, take care of it before I commit, for now rename it and keep working. Need these changes to go on a branch? As you said, "git checkout -b <branchname>" and BAM! I'm on a branch (most unlike SVN branching). Contrast that with something like perforce (and I know the parent was comparing to SVN) where it intrudes into my workflow whether I want it to or not. p4 edit? pshaw! I have been using the "git p4" module for a few years now in my corporate p4 environment. It ain't native git, but it's better than p4 IMO.

EDIT: Come on. If you disagree with me, don't downvote, reply so you can contribute to the conversation. Coward.

It sounds like your parent is working within a team with a defined git workflow that they find too heavy but don't have the final say in defining.

I've just started using git recently and have completely fallen in love with its power and flexibility.

But as someone just starting out, I can relate to how demanding git can _seem_ to a beginner. Say I have some refactoring ideas floating around in my head. I could either begin accommodating for these changes in git (namely branching, perhaps also chunking my edits into commits) or start coding and go back and handle commit isolation and branching later.

For me it can seem like git is getting in the way if I select the former method, and that the latter is just messy and cumbersome. But the more and more time I invest into the tool, both my efficiency and the cleanliness of the code base increases. Persevering through the higher learning curve (which exists probably due to a minimal (bad?) interface wrapping a set of concepts that can best be understood visually à la Dwarf Fortress) appears to be a worthwhile investment.

The nice thing about git, is there is a ton of possible workflows depending on how much you care, how knowledgeable you are about git, level of effort willing to put forth, etc.

I've found my workflow in git has changed over the years... just like my coding style does.

> In the past, version control was something that existed but you never had to think about.

I think its the complexity of git that forces you to think about it. It's really not that user friendly, in comparison to SVN for example. Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).

The big fallacy for me of distributed version control systems is that we all use them in a centralized way anyway (commit loses value, code does not exist at team level until pushed). It just adds another step to your work flow (code->commit->push vs. just code->commit), but the gain isn't obvious.

Another SVN fan unconvinced about git.

> Recently I had to teach a very senior DBA git so that he could check his SQL scripts into our repos, and I kept on thinking it would be much easier to teach someone SVN (actually he already had experience with that).

Create some aliases that make it as close as possible or as simple as possible for them. There's no need to force someone to learn the whole tool if they only need a subset.

I think the core problem is that git is designed for large fast moving code bases with several contributors. So in the process of teaching a newbie git, you can't help but teach them all complicated use cases that show up in a regular workflow. But you don't have to use git this way. You can use it like SVN where the only difference is the index (push pull)

If you're that concerned about "commit + push" vs. just "commit" then you might want to just alias "commit" to "commit + push" :).

Anyway, I think I get what you're saying wrt. less experienced users, but I found that with the proper explanation it wasn't actually that hard to get the point across. When explaining it to my coworkers, I've always tended towards focusing on the human factors. Namely things such as: "Don't you wish you could have taken that commit back?" (rebasing), "Everyone has a backup of the whole history"[1], "Hey look, if you mess up a merge, you can just say 'git reflog' and figure out where you were before everything got messed up", etc. If people can see the advantage in terms of their professional goals they are usually very willing to learn even relatively arcane tools such as git :).

[1] I know that's a white lie, but...

Just curious how much experience to you have using git? Days, weeks, months? Have you worked on a team using it before or just by yourself? These aren't loaded questions.

I've been using it full-time for the past 2-3 years, in teams of roughly half a dozen devs. I still use SVN for my part-time open source work out of choice.

At this stage I'd say I'm very comfortable with git at the CLI (I only ever use source control tools in CLI mode), but it took me a long time to get there.

> It's like timesheets for your code. Not a big deal, but ever so slightly insulting that you have to deal with them.

Honestly, I'm not sure you have realized the true power of git branching.

Here is our typical workflow at work:

1. Branch master to topic/feature branch

2. Work on feature branch, push feature branch to remote

3. Push of feature branch to remote triggers a Tddium test run.

4. Deploy feature branch to a staging server for internal review.

5. Make fixes, adjustments to feature branch and push to remote, which triggers more Tddium test builds.

6. Once things are looking good, we pull --rebase master, which pulls down everyone elses changes to master.

7. Rebase the feature branch off of master, resolve any conflicts.

8. Merge feature branch into master and push.

Above, branching allowed me to:

* Save my own personal branches to a remote repo where they are backed up,

* Offload my test suite to a 3rd party,

* Allow me to deploy a feature branch to a staging server all without messing with the master branch at all.

I can also squash or rename commits on my branch easily and cherry-pick other commits from other branches without worrying about master. I can also VERY EASILY switch to other branches to work on other features and bugfixes as they arise. I normally work on 2-4 diff branches per day. Try doing any of that in SVN and be in for fun ride...

Which does nothing to improve the core problems with your workflow :)

Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

Working too long on your branch will only make mergers more painful later.

We use svn and git, but the workflow is still local fast tests before even branches commits. No personal branches, only features, and update those often because they're not exclusively your silo. And commit/merge to head often. And head is the only place where you get the 2h integration test run. Because otherwise, you'd wait 2h after every branch commit (which we know nobody can do)

> Which does nothing to improve the core problems with your workflow :)

Not sure what you mean. I state above how it helps my workflow.

> Offloading tests to 3rd party will not help you ensure that tests run fast as they should.

That's not the main point of CI. The main point is both: as a sanity check for tests pushed to the remote and also to not waste your time and CPUs running tests locally.

> Working too long on your branch will only make mergers more painful later.

I easily rebase off of master on a daily basis with git, no issues there.

rebase is not the same as avoiding merge problems.

what does it help you if you and other dev have their, often rebased or not, branches for a long time? the first one will be fine, second will have merge hell.

honestly, you are only comfortable with that setup because you probably work alone on a small team.

edit: and dont get me wrong, if that is the case, you are using the right tool for the job. i would love to be able to not rely on regular atomic commits in my huge dysfunctional group.

(Not the OP, obviously.)

> rebase is not the same as avoiding merge problems.

Yes it is. The point is this: Everybody rebases against "what is to become our next release" on a continual (daily if not more frequent) basis. If you have acceptable levels of unit testing and integration testing on your feature branches there's usually no problem with early (that is, way before the sprint ends) merging of feature branches to master. If your team is really paranoid and all your team's feature branches tend to pile up until the last day of the sprint[1], you could forcibly (via process) stagger your feature merges so that they're always at least 1 day apart to catch any bad interactions between features.

[1] This is indicative of other problems to do with process/management, so take the next bit of advice with a grain of salt.

> You're doing silly housekeeping tasks like reverting a change that you accidentally checked in to the main branch then branching and copy/pasting your changes back into the IDE just so that the source control system (and possibly some ops overlord somewhere) doesn't get mad at you.

I'm sure if you were a release manager, or the lead of a sizeable team, or the owner of a busy open source project, you would feel very differently about 'silly' modularised changesets and branching.

I don't get this "it makes things easier for a select few, so everyone else just has to suffer an over complicated system" thing. We should make the few suffer instead of the masses; optimize to lower global suffering. It should be possible to build a system that exposes different interfaces to different users, shouldn't it?

Modular commits with good messages are analogous to well-written code with good documentation - both are not terribly important (though not harmful either!) for individual contributors but absolutely critical for teams and especially those working at the aggregate team level, like the release managers and team leads your parent mentioned.

Well it is. You can make branching as complex or as simple as you want. Where I work the developers are only ever exposed to the feature branch they are working on, which is even created automagically for each Jira ticket from the correct release/integration/dev branch. So for a developer it really couldn't be any simpler.

This guy in the crowd finds it very convenient to be able to commit locally so that you can easily get back to an earlier state of the thing when you fuck up or wants to explore another way to do it.

The masses have spoken and they want git.

The masses are split with still a slight preference to svn: http://www.ohloh.net/repositories/compare

(I'm sure there are other statistics out there, but your comment had made me curious and this was the only one I knew of)

Would be interesting to compare that to repositories created in the last 2 years or something. It might have quite a different distribution as some old projects probably have kept the vcs they started out with.

Git is not easier, it's better! You can do with git what you can do with svn; just commit, push, pull to a central server, no branching, no merging, no rebasing, and voila, you got the same workflow. Nobody forces you to do any complicated if you feel disturbed by it.

A screwdriver is much more simple to use than a drill, but if you have to choose one, which would you build a house with?

I'm a huge fan of Git and I think it improves my coding life drastically. But I completely agree with you that git is not better for every task. You either need a shell (which many modern coding tasks simply don't require at all) or you need a reasonably abstract GUI tool (I only know the GitHub GUI tool to fulfill that requirement, all IDE integration I know off sucks). But even in the case of well designed GUI tools you often do things like "create a feature", "send pull request to main repo", etc. If there is git underneath or any other version aware data storage doesn't really matter. A couchDB might have been a fine choice as well. So the only real use case is when you work in shells anyway and when you require the more complex git capabilities. Therefore I don't think it should be the major, hip tool everybody uses and I hope the world soon realizes this and creates tools for every day usage with an every day amount of power under the hood that can be handled without a mastery in git foo. (After having said that, I want to remind the reader that I myself love, need, want and use git with nearly everything it has to offer, but I had the time, energy and interest to dig deep into it for a long time)

This notion works as long as you have a centralized team working on a single code base and they can coordinate through other means. Once you have different people - and potentially even different access levels - working together, you need to be mindful about version-management, be it svn or git.

I have exactly this situation at hand at the moment. We are contributing as much as possible to an open source project. However as buisness goes, we need certain extensions to this project which clearly fall under our NDA, so I can't contribute them back. That's precisely where version-management becomes important, and where real benefits of git kick in.

In this case, I can do a bit of trickery by chaining repositories: I have a public repository for our contributions, which can open pull request to up-stream. Behind that, I have an internal repository, which has two read-only remote repositories (upstream, and our public contribution repository to fast-track certain changes). From there, you can do the changes in the right repository and need to obtain the changes through the right remote repositories.

Just be glad you never had to use Visual Source Safe. Makes svn look like a dreamland.

I have a confession to make.

At my first job (small shop with three devs) they were using VSS and it was so much of a diasaster that I took it upon myself to prepare a sizable document on why do we need to move off of VSS to something like SVN. Manager's response was something along the lines of "I don't trust those fancy merge algorithms, unlock-modify-lock is the way to go". I couldn't convince him otherwise, he wouldn't even agree for a itsy-bitsy pilot project to test the waters.

Having exhausted all my options, I did two things. First, I "Got Latest" of the entire repository. Second, I wrote a smallish script that would overwrite a single random byte in a random number of files inside the VSS database directory and scheduled it to run overnight. Of course it would self-destruct upon completion, so that no traces were left.

The next morning, VSS was on it's knees and nothing could be done. Turned out we had no backups.

And this is how we "migrated" to SVN.

We migrated SVN exactly the same way. Except I didn't write a corruption script. Turns out VSS was capable of corrupting itself beyond repair with no help from anyone! Or wait, did you work in my office?

I'm tempted to try this with our TFS setup [1] (VSS in all but name [2] with lots of "features" unrelated to version control)...

1: Yes, I know that TFS supports git repositories. But I have the same issue: Convincing management that this might be a good idea.

2: Actually I consider TFS's source control part worse than VSS. While VSS was a hack, TFS is sold as 'enterprise' software. And it's unbelievably bad (again, only talking about the source control part and leaving out all the other things it can do. Maybe some are less half-assed than the source control part is?). Given the choice I'd pick CVS over TFS.

TFS using GIT isn't too bad. You then get GIT, with the project management features of TFS.

TFS keeps all the crap inside an SQL Server database, so it might be a bit harder to perfom the "trick".

Well that was an option. An other one would have been to point out that svn does support lock-modify-unlock so that was no issue.

I don't think that the manager's actual reason for support for lock-modify-write. I think he was just opposed to changing anything in the realm of source control and this was just a convenient rationalization.

Today's example of this would be TFS or Sharepoint.

My first job out of college happened to involve me working tangentially with the folks who maintained Visual SourceSafe. They didn't particularly like it either ;)

Once upon a time, I actually thought VSS was the shit. But that's because crappy source control is better than no source control.

I beg to differ.

Take a little look at this: http://www.highprogrammer.com/alan/windev/sourcesafe.html

At least with NO version control, you know you're not protected. Bad version control, such as VSS, gives a false sense of security that you're protected when you're really not, which is worse.

after having to use it for one job it is now a required question I have about the organization using git/mercurial/perforce before I'll accept a job offer.

I used to admin VSS for a team. We had to run a nightly scheduled task to uncorrupt the database.

We ended up buying perforce which saved our arses but the days of VSS were dark days indeed.

And clearly you never had to use "clearcase" then :)

OH GOD CLEARCASE

I put ClearCase on an old version of my CV, because I was nominally the sysadmin in charge of it for six months. I still get calls about it. Those last ClearCase shops, they're getting desperate.

As a question, how do you rate Team foundation server?

You can get some interesting usage statistics from job tracking websites such as itjobswatch.co.uk. In the source control market, Git is now the most widely used (3461 jobs) with Subversion second (3181) and TFS third (2035). Mercurial is a distant fourth with 268 and just about everything else seems to have fallen off a cliff in the past couple of years or so.

The other thing that Git has achieved is that it is now the de facto standard for source control in a way that no other source control tool has ever been. An increasing number of ecosystems don't support anything else and most best practice guidelines that you find on the web assume that you're using it, or else tell you to switch if you aren't.

I suspect that it won't be long before not using Git will start to count against you in the jobs marketplace, whether you're a candidate or a recruiter.

Yeah, I just picked up git about 3 years ago and I probably wouldn't even take a job if they were using one of the other DVCSs.

A lot of game studios use Perforce (p4) - while it's not distributed, it seems to be easier to non-programming folks - artists, producers, etc.

And git can still be used along with it - For some of the lib/tools that I do, I create a ".git" repository living along with p4, and work like this - then submit in P4.

Also, "exclusive checkout" is something that doesn't even really make much sense in git, but is important for people collaborating on non-mergeable assets (3D models, textures, etc). We end up using git for code and in-game assets but p4 for source art assets.

Some small game studios also don't use git. Famous indie developer Jonathan Blow[1] said they had 20GB of data on a svn repo 6 months ago: https://news.ycombinator.com/item?id=6745412#up_6746172

[1] Braid here if you haven't: https://www.youtube.com/watch?v=uqtSKkyJgFM

Perforce also handles large binary blobs better as well, which is super important in game programming.

Where I work (game company with about 20 people) we solve this by versioning unimported assets separately (in svn, because that's what we used before git).

We bring them into the git repo after running them through our asset pipeline, which means that there are really never any merge conflicts for them and every checkout is a playable version of the game with art.

This reduces the load on git by a lot, though we still tend to have .git folders measured in the tens of gigabytes, which is getting up there.

How is git with a gui hard for artists? I get that they don't want to stage their changes and commit them from a terminal, but you literally just pick your files and write a note about what you did before hitting the commit button.

It's not the GUI that's the problem. The difficulty comes when you pull/fetch-merge and somebody has pushed a change in a file you're editing. Binary files aren't easy to merge, so now you're going to lose your changes, or they're going to lose theirs. This is the problem the check in/check out (lock/unlock, whatever) mechanism is designed to solve. It gets in your way a bit when working on files that could be automatically merged, but it's completely necessary when working on files that can't.

A system like perforce stores the files read-only on disk, and makes them writeable when you check them out. To do that you visit the perforce GUI and try to check the file out; if somebody else has the file checked out already, the server will tell you who it is, so you can go and talk to them and decide how you're going to order the edits.

(Because of the read-only flag, even if you don't check out at least the files you know you'll need before you start work (which you should do), you at least find out immediately when you try to save. So even if you then end up losing a bit of work - it happens - you at least won't get too far into your work before finding this out.)

I think the bigger point is that game studios check in assets. And you don't want the complete history of game assets over 2 years of development and iteration on your machine. And git is generally not optimized for huge binary files.

git does have very very bad binary asset management. It doesn't really work like svn/perforce in a logical tree structure and each commit has it's own hash and isn't necessarily ordered so there ends up being a _lot_ of copies of binary assets (git -unconfigured- will attempt to store deltas between changes but it can't do that with binary assets... and over time gets _very_ slow with large binary assets).

This isn't necessarily horrid for web apps as the images aren't big. But when you're talking about 500mb PSD files and massive massive 3d maya/max scenes it's horrid.

http://stackoverflow.com/questions/3055506/git-is-very-very-...

FWIW, git will never store two copies of the exact same file in the same repository, since the blobs will have the same SHA-1 hash.

Right. But when you change one thing in the the PSD git can't do a diff and store the diff. Which means you now have basically the same 500meg file duplicated.

SVN and the like will attempt to store the binary deltas instead of duplicating the files. I don't believe git can actually do this due to the way branches / git itself works (it doesn't have a simple #1 - #2 - #3 ... #n commit chain setup)

There are plugins for handling binary assets better but they aren't great. and/or it just makes it less intuitive for the non-programmers which really defeats the whole purpose.

I absolutely _love_ git and I'm 99% sure this issue will be worked out at some point. I've seen teams just use git for the code and then use something else for art assets (alien brains or something).

Git packs are mostly made up of deltas. Git is remarkably efficient at diffing files. And because it's all handled at the the storage level it doesn't matter what order the files are in, it generally packs all the revisions of a file from largest to smallest with the a compression window several versions wide. The problem is that it's still a lot of data when you have significant binary assets.

Edit: The default is to delta files up to half a gigabyte in size.

Sure, but that rarely matters here, as artists are working on the assets.

Having used both extensively, Perforce workflow is just a lot easier for a layperson to understand. Add files to changelist, move files between changelists, remove file from changelist, check it in. It has a nice GUI and command line tools. With git you have staged files vs commited files, commit vs push, multiple commits and the need to rebase, difficulty of removing a file from the commit before push, not to mention lack of a good built in visual merge solution tool and stuff like detached head state. Git also has a more complex command line, and multiple UI choices, none of which are great. I love git and it is my vcs of choice, but just because we know, love, and understand it doesn't mean intern Katie from the art team is going to feel the same way.

I think perforce deals with binary files better too (not sure of the details)

And what when, suddenly, vim appears and they have no idea of why or how to close it?

At what point would Vim appear when using a gui client for git?

the github client is actually extremely artist friendly.

Not much commercial game development goes on on github, which IIRC is the only way to use the github client. (Where I work we have a local gitlab.)

Since commercial developers on github presumably use private repositories, how would you tell?

You can use the github client with non-github repos as well.

But not particularly stable. At least when I tried to use it about a year ago

As is sourcetree, and not tied to github

Plastic SCM is targeting Perforce users who want to go to a distributed model.

I really hope you're being sarcastic. If you're turning a job down because of the VCS, hopefully you've got a surplus of work to choose from.

I understand the sentiment: the fact that a company uses Visual Sourcesafe, or ClearCase, or something else terrible tells you a lot about their culture.

I'd be inclined to agree with you in some cases ("any port in a storm"), but otherwise I would view a VSS or ClearCase shop as one that's possibly on the wrong side of the technology curve. I have worked with VSS, p4, cvs, svn, hg, and git (and arms length with evil things like ClearCase and more primitive stuff like RCS). Everyone should have an idea of the minimal toolchain they want to work with.

But that aside.. massive props to the Git team on 2.0!

First month at the previous gig was spent writing an SVN-based implementation of SCCS because their workflow required SCCS locking etc. and they wanted to move the backend to SVN for the eventual "moving the developers to not all working in the same directory" project.

It was a very tearful month.

engineers do in the bay area.

and in seattle

I can almost understand with something like Subversion (which seems to subtly skew the entire development process to work around the friction some of its basic operations introduce), but not even Mercurial? :(

Not even Mercurial :) Haha j/k I actually don't mind Mercurial, but I'd still rather work with git.

They're essentially identical. Mercurial just has slightly easier to understand syntax and and a cultural bias against rebasing.

Nope. Mercurial devs rebase heavily during Mercurial development, for instance. It's Changeset Evolution [1] that makes history rewriting _safe_.

[1]: http://mercurial.selenic.com/wiki/ChangesetEvolution

I've been using git-svn for workflow the past 2 years or so. It's not perfect, but it seems to cover all the use cases I've had and integrates well with the regular svn workflow.

> I probably wouldn't even take a job if they were using one of the other DVCSs.

Why? At my current workplace, I converted a svn repository (with 6 years of commits) to git without any hiccups! I did not even lost a single commit!

I also detached a huge binary directory (they committed everything to svn...) and made a different repo for it.

Also you got git-svn, with you can seamlessly commit to an svn repo and still work in git on your local machine, nobody will notice, except you!

Its a surprisingly awesome s/w for a '2.0'

Well said. The funny thing is, switching from svn to git was what it felt like to switch from from other SCMs to svn.

I think git is going to prove to be one of those pieces of software that is just transcendent.

git (and github) has been transformative for the D programming language project, as it allows easy collaboration with people all over the world.