Hacker News Reader

Comment by endeavor | Hacker News Reader

Very nice set of diagrams.

But every time I see something this I have to ask myself again why I'm just not using CVS (or SVN, i.e. a simpler tool).

View on HN

Because experience shows that on any sufficiently long-running project, you're going to need some of the power that CVS/SVN don't have.

You're wrong, git is simpler. I mean it has a simpler architecture, a simpler foundation. This simpler architecture means some changes in your habits and, because it is a new tool, an interface that is a bit rough on the edges.

Git simpler? I really don't see how. SVN is focused on having one branch, canonical copy on the server, and you have two big buttons to pull down the newest updates to your copy and also to put your own updates into the master.

That seems intuitive because you're used to such a workflow. As someone who started out with git and then learnt about SVN, I found the non-distributed approach somewhat puzzling and limiting.

I've used git much more than SVN. SVN's model is definitely limiting but it's very simple.

My opinion in the svn vs git debate:

Unless you are working across multiple groups with developers in different time zones and a choppy set of releases you'll see almost no benefit from git.

However, if you are in that situation the benefits are large and immediate.

I love git even for personal single-developer projects.

I do too. I'm just saying the smaller the project the more the benefits tend to lean towards personal preference over empirical evidence.

I think eliminating the need to set up a SVN repository for very small projects is a major boon.

Well, if you enjoy 'log' pulling info over the network (slowly), .svn in every single folder, barely useable branching, no reabase, no stach, no… well maybe you have the point. Otherwise not even comparable. When I first saw Linus' talk on git where he was very harsh toward SVN uers I thought "WTF". Then I tried git and had to admit that the man was right.

Since Subversion 1.7 (2nd half of 2011) it keeps only one .svn folder in the root folder.

Local commits and huge speed increases are some of the immediately available, tangible benefits of git over SVN.

Plus, you don't have to migrate your codebase to another SCM tool if the project unexpectedly grows into a larger one.

Even when working on my own, I get a massive benefit from git. I think people end up being very polarised here.

The biggest benefit I get is that I can work on a set of changes as a set rather than a linear sequence that only ever goes forwards in time. I use microcommits. As I make progress on a feature, I discover necessary refactoring that I would ideally have been done before I started to add the feature. Interactive rebase allows me to make this so, and the result is that when I am done I can review my own work and check it for correctness with much more confidence than otherwise.

When working in open source, you're expected to provide a patch series for easy review. Git lets me produce such a thing with the same workflow.

Developers who don't wish to work this way, or are unaware of the benefits that this can bring, use git linearly and will see no benefit over Subversion.

I was going to point you to http://whygitisbetterthanx.com/, but it seems to have been replaced with http://git-scm.com/about/.

well in my case it's because SVN branches are useless. I still find mercurial much easier to use than git though.

Reply on news.ycombinator.com