Hacker News Reader

Comment by danohuiginn | Hacker News Reader

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.

View on HN

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