Hacker News Reader

Comment by fendale | Hacker News Reader

I have just got a rather large team ( > 100 people) using Subversion - from my experience, I noticed two things.

Firstly, most developers I have encountered in big corporations (and India) don't even give version control a thought - I thought it was programming 101, but I was shocked about the resistance I got when trying to persuade the team to use anything.

Second, the people I was trying to get to use version control could barely grasp the basics - branching, merging, frequent checkin's, updating your working copy - alien concepts - and that was using Subversion. I cannot even imagine trying to convince them to use a distributed model!

So my point is - distributed version control is probably great (I have never used it, but I have read a bit) for the clued in 20%, who work with others from the 20%, but if your team involves people mostly in the 80% don't even think about it - Subversion will have a market there for a long time to come ...

View on HN

I cannot even imagine trying to convince them to use a distributed model!

You're assuming distributed version control is harder to understand than centralised version control. That certainly hasn't been my experience.

Using svn or cvs, I find myself rummaging round in the docs to do even quite basic things ('recursively add everything in this directory', 'maintain a personal branch of an open-source project, and keep it in sync with new releases'). I've found bazaar and mercurial much more intuitive.

Maybe my experience is atypical. Maybe it's because of the particular qualities of the programs I've used, rather than centralised vs. distributed. But it's not obvious that distributed is harder.

You may well be correct - perhaps the distributed tools are easier - I need to get one of them installed so I can play around with it to figure it out.

That said, if people don't get version control at all (yip, there are plenty of them) then its probably going to be harder to convince them of the merits of both version control and a distributed model at the same time.

I have certainly learned in the last few month that changing the direction of a large team is no easy task, and convincing people to use any tool that is even slightly off the beaten track is going to make that task even harder.

Its sad - I wish there were more curious, keen to learn people when I work!

In my experience, the thing people have most trouble with using Subversion is moving directories around. They expect to be able to open up the Finder (on OS X) and drag a folder somewhere else - but doing so without using "svn move" results in massive confusion later on as the hidden .svn directory gets moved at the same time, breaking things.

Many (all?) distributed systems solve this issue by keeping repository metadata in one place at the root of the project rather than spreading it around in lots of .svn folders.

The thing you're looking for is called "git-svn". It's built into git, and it lets you use git with your office's svn repository.

You do have to accept some constraints in order to use it successfully -- basically, git-svn doesn't seem to understand merging back-and-forth between different branches very well, so it encourages a much more linear, one-branch workflow than git does -- but it is still a huge improvement over stock svn, and it lets you inch your way into git, and gives you a platform from which you can lure your fellow employees into git one at a time.

Reply on news.ycombinator.com