Subversion sucks, get over it | Hacker News Reader

Subversion sucks, get over it

andreasjacobsen.com

8 pointsnickb23 comments

I don't get all the continual subversion hate lately. Is it really that important? Maybe if you have 100 contributers to your open source project it starts to make sense, It's just becoming a bit tiresome reading the same old lists of why subversion sucks and why git is the best thing since sliced bread.

Different tools suit different uses. Git seems good for open source tons of developers tons of patches/branches etc.

It makes no difference whatsoever. Some of the largest and most successful open source projects have done fine with CVS, or with nothing at all.

I would be really worried about an open source project without a source control system. Actually, I would be worried about any project, open source or not, developed without using source control.

What large and successful open source projects have done fine with no source control? Did any of them chose consciously not to use source control? I'm really confused as to why a multi-developer project of any kind would ever not use source control.

I had the impression that in the '90s, the Linux kernel was managed just by e-mailing patches around, before adopting Bitkeeper, and then git. Things are much easier now.

"The Linux kernel source code used to be maintained without the help of an automated source code management system, mostly because of Linus Torvalds' dislike of centralized SCM systems.

In 2002, Linux kernel development switched to BitKeeper... "

http://en.wikipedia.org/wiki/Linux_kernel#Revision_control

Bizarre(-ng? just kidding!) but true.

"Git seems good for open source tons of developers tons of patches/branches etc."

If that's all Git seems good for I recommend you spend more time playing with it (or Mercurial if you want). There are many benefits to using something like Git even if you're not going to share the work with anyone.

Why?

Why not just use it for the features you need?

I mean, if you spend a lot of time researching features that you are not currently using, and you are currently maintaining your code enough to reach your goals, aren't you just wasting your time?

I hate to use the cliche of Ford and the faster horse, but sometimes figuring out whether or not you need something involves trying it. It's very easy to dismiss things you're not familiar with as things you don't need. For the longest time for example I thought I didn't need the power of Emacs. I finally tried it for Lisp development and now it's definitely something I need. Similarly back when I used Windows I didn't think I needed Linux for anything.

I've felt similarly about Git. I'm orders of magnitude more productive than when I used svn. To me the time investment has been well worth it.

For me, there's a modest amount of activation energy associated with trying a new SCM. For work, there's an INCREDIBLY large amount of activation energy to move all of the developers, scripts, etc, off svn (although we don't develop open source).

I think "you just need to try it" is the wrong approach. I want to know /why/ I should try it. I want to see my work flows called out and the minutes/hours I will save by switching from svn to git explained clearly. Svn certainly has its pain points, but I haven't seen a concise, easily digestible outline of what git (or its ilk) will get me.

Branching off of your argument, there's a significant amount of activation energy to start a new svn repo, compared to mercurial or git. I find that when all I need to do upfront is type "hg init", I end up using VC for far more. For example, all the dotfiles in my home directory, my window manager setup (a somewhat-patched dwm), and my bin dir are in an hg repo. It makes "moving in" to a new computer (and syncing with my laptop) much easier.

You can use mercurial as if it were svn, just an svn that isn't a pain in the ass to set up, and that makes free backups for you automatically. Anything past that is just a bonus.

  andrew-desktop:~/x> svnadmin create ~/repo/x
  andrew-desktop:~/x> svn import file:///home/andrew/repo/x/trunk
  Adding         y
  Adding         y/example.yy
  Adding         example.txt
  
  Committed revision 1.

Sure, it's about 10 times as many keystrokes, but it's not a great burden.

Actually there is zero effort required to use git in an environment that already uses svn, git integrates incredibly well with svn.

"I want to know /why/ I should try it. I want to see my work flows called out and the minutes/hours I will save by switching from svn to git explained clearly."

Sounds like you're waiting for a salesperson. Good luck with that.

Maybe salesperson shouldn't be a dirty word then. I think the burden is on the creator (and or proponents) of software to explain to others why they should use it. Would you argue otherwise?

I've been watching the tech industry for some time, and I've seen a lot of different versions of the same thing. As a user of Groove, I'm an evangelist when it comes to P2P/Non-server file repositories -- we need to see a lot more apps like these.

But looking at it long-term, 99% of these "improvements" are cool, make a few operations easier, but aren't worth the investment in terms of just using the tools as a way to get somewhere. As techies, we're constantly getting sold the bells and whistles and constantly losing track of what the big picture is. Whenever somebody says "you don't know the feature you want until you try the app" that's kind of a red flag for me. If I know the features I want and am happy with what I have, what, aside from "wow!" are new features going to get me? Most likely they will appeal to my technical side, not my business-get-things-done side.

Try out the new features and see for your self if they get you anything. They might just be "wow" features, or they might save you significant amounts of time in ways you couldn't have imagined before. Unless of course your imagination is far above average and you have the rare skill of knowing in advance exactly what you want and how you want it to work.

Dude. I got something like 30 or 40 tools and toolsets that I use on a typical project. For each of these categories, there are multiple contenders.

My source control system does what I want it to do. It doesn't get in the way of production. I understand p2p offline/online editing but we don't need that right now.

I come on HN to play. I've already spent too much time just talking about the tool than the value of the tool itself. As a value provider, I need to concentrate on my users and how much value I can provide for them. There are lots of distractions.

If subversion sucked for my use case, I would play with git. But it doesn't. svn stays out of my way, and works for everything I use it for.

For me it's like arguing that I should encode my music as ogg rather than mp3. Who cares?

Apache has hundreds (1000+) of committers across it's 60 projects, all of which successfully use a single SVN repository (which is how subversion was designed to be used).

There was a recent comment on here that was something like "I can see why you were downmodded, liking Quickbooks and all, but..."

WTF is up with all of this brand-clanning? As long I use an OS, have a SCM system, use some sort of accounting package, etc -- do we really want to gang up and make some kind of decision as a herd? Most products on the marketplace do most of the things we want them to do.

I've been using Subversion for a small effort with 4 programmers for the last six months or so. Works fine. I love P2P apps, but the argument made on this site was unpersuasive.

I like git, but until there's a compelling version for Windows there's no chance in hell it can be used to replace subversion. We have mostly Linux and OS X machines at work but we do need to do some development in windows to run emulators and such. Also what about all version controlled challenged that use Eclipse or Tortoise to work with the repository - how would they handle git?

Also lol have everything in a separate repository. Who wants to maintain a list of repositories? Oh, no to check out THAT project you need to go to repository X... when people have trouble remembering a single subversion URL.

I would have liked a comparison of the same problems in Git, which seems to be the version control system that is taking over SVN's reign as king.

Arrogant much?

Reply on news.ycombinator.com