It's great if people want to have the choice for subversion, tho. Some people just prefer the tools they are used to instead of learning new, more powerful ones. But to use that as argument that svn doesn't suck is not a very strong point.

Are there better tools ? Is Git better ? Maybe, but different tools for different uses. For me personally, Subversion does not suck, and I don't need a "better" tool.

It works, and gets the job done for me !

git init git add . git commit -m "blah" git push origin master

git branch name git checkout

easy-peasy

The popular notion isn't that Subversion sucks, but that it's pointless. The claim I hear is that it's a reinvention of cvs, but it doesn't actually improve much. Personally, I had to learn cvs, it's simple enough for my needs, and I see no reason to switch to something that's fundamentally the same thing.

I think most cvs users are in a similar situation as me. We know Subversion is better, but those benefits seem marginal and not worth the effort to switch.

However, on the 'switch from CVS to SVN', I'll comment and say that SVN is far superior to CVS.

The whole 'changes committed to the repo up the entire repo version' alone make this worthwhile.

SVN is also less arcane in its usage.

SVN has better tools for, well, everything.

SVN integrates well with all major IDEs (mine being VIM, but also Monodevelop and Eclipse).

The switch from CVS to SVN also made our releases much easier to manage (merging branches is fairly trivial and tagging is a no-brainer).

If you're using CVS in a company, do yourself a favour and switch to SVN. The basic concepts are the same, so re-educating developers takes all of 5 minutes.

Maybe git is better... maybe it doesn't matter enough to bother changing. But you have to admit these types of things are more about what is "in fashion" than what is better suited to a particular task.

Things go in big cycles. For a few years centralization is excellent, offers massive benefits, then suddenly distributed is excellent offers massive benefits etc etc As the post hinted, I wouldn't be surprised if 5 years from now git is pronounced as a terrible idea, and the trend setters go back to something more like svn.

Some people and some projects prefer centralized. That's fine. But you can't build a distributed version control system out of a centralized one.

DVCS's let you branch off, experiment, and if it works out you can push everything into the main tree with the history included.

Git, on the other hand? No problems.

Seriously? I don't remember ever seeing that, perhaps it's restricted to a certain O/S or version.

Easy when it comes at the cost of features is another way to say it's OK to be ignorant.

It's one thing to make things as easy as they can be.

It's one thing to not complicate things unnecessarily.

But it's a whole'nother thing to make things easy at the cost of features and power.

Anyone can make anything easy if they are allowed to cut enough features.

Why does everyone assume that designers are stupid luddites who can't wrap their heads around complex systems? UI design is full of nuance and complexity. It's insulting to designers to assume they cannot deal with DVCS.

Meanwhile: To claim that SVN is intrinsically easier to understand than DVCS is to be very shortsighted. Subversion is a more mature technology: It's eight years old, and is conceptually based on CVS, which goes back to the eighties. DVCS is all of eleven years old in its eldest incarnation (according to Wikipedia) and the current generation of tools (git, Bazaar, Mercurial) date back only to 2005.

DVCS is a maturing technology. One of the things that happens as a technology matures is that people learn better ways to explain it to new users, build better interfaces, build better infrastructure.

If you don't think that DVCS makes enough sense to non-geeks yet... give it time.

There's no reason a DCVS can't have a clean, easily usable interface (darcs's is better than git's, for example), but the git developers have focused on features and raw power over usability.

I don't think that's necessarily so. Have you ever tried to get an office full of people to collaboratively author a Word document? What's their instinctive behavior? They all grab copies. Then each of them hacks away on their copies. Sometimes two or three of them email their hacked copies to each other and mash them up, using cut and paste. Eventually some poor SOB has to get everyone to email over their individual versions so he can merge them. Hopefully they've all been using Track Changes (which is, in a sense, a poor man's facsimile of a single-document DVCS!); otherwise it's an even bigger clusterfuck.

That's a distributed model. Ever since the invention of photocopiers and email attachments, people have had to develop a very good understanding of how that model works, and how it fails.

It's tempting to think that the way to sort this out is to centralize it. But in my experience, centralized document-management systems are not that intuitive, which drives people to secretly work around them. ("Why can't I save my changed document on the shared drive? Oh, no, Joe checked it out and then went on eight-week vacation! I'll just stash my edited version on my local drive and distribute it via email." Or, "I created an alternate version of the doc, but I don't dare upload it to the shared drive because I might make another mistake and overwrite the official version. That always makes the admin really mad. So here it is on this USB stick.")

I think the most confusing aspects of version control are the navigation of history (just look at the wacky extreme that Apple' Time Machine designers went to in order to make it very obvious that you're looking backwards in history), and merging, particularly merge conflicts. But those aren't special features of DVCS; they're tricky no matter which VCS you use.

Whenever someone says "even X can use it" about some technology, it usually means that either X is stupid, or X is very busy and has no time to waste on "yet another Y".

That said, git can be used in a perfectly centralized fashion, just like SVN. (I use it for automatic synchornization of all my files across 3 laptops via central NAS). And there are some cool GUIs popping up.

But, this growth industry of training doesn't reach designers, clients, and other non-programmers, because this stuff is just too complicated for them.

Designers are often helpful for a reality check. People should listen to them more!

(There is also nothing about DCVSs that necessitates a bad UI, of course.)

Huh? Am I the only one who finds Subversion to be very confusing, at the conceptual level, compared to git? All that file-by-file history tracking, just waiting to trip you up when you try to move a file around? The fact that branching in SVN is hopelessly entangled with the concept of copying directories around in some remote repository? Here's the canonical example from the SVN book:

  svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Creating a private branch of /calc/trunk."

  git clone git://github.com/mechfish/calc
  cd calc
  git branch my-calc-branch
  git checkout my-calc-branch
  # ... fiddle around, then when it's time to go back to master ...
  git checkout master   # note: no need to cd anywhere

  git push origin my-calc-branch:refs/heads/my-calc-branch

  git config branch.my-calc-branch.remote origin
  git config branch.my-calc-branch.merge refs/heads/my-calc-branch

  git checkout my-calc-branch
  git push

The biggest problem with SVN is that getting started with it is so hard. As a git user, if I have a directory and I want it under version control, I do this:

  cd my-directory
  git init
  git add *
  git commit -m "Initial commit"

  cd my-directory
  git commit -a -m "I committed today"

As an SVN user, you need to find a hosted repository, get admin permission on it, set up the canonical directory structure -- being very careful to heed these words from the SVN book (you did read the SVN book, right?):

While Subversion's flexibility allows you to lay out your repository in any way that you choose, we recommend that you create a trunk directory to hold the “main line” of development, a branches directory to contain branch copies, and a tags directory to contain tag copies.

... and then import your project, being sure to get it imported into /trunk and not into /trunk's parent. Then you have to check it out -- being sure to check out /trunk, or at least to do all your work in /trunk, lest you screw yourself up or confuse yourself.

So I assume that by "ugly, needlessly hacked-together systems" you mean "systems that make you use the command line". The only reason Subversion seems at all simple to non-geeks (to the extent that it does, which isn't much of an extent) is that the authors of tools like TortoiseSVN and Versions have sweated bucketloads of blood to design beautiful interfaces which hide all this cruft from the end users. DVCS will get there. Give it time.

I use Mercurial, but I don't have any grand illusions about its interface being ideal. It works well enough for me, though. (I don't like svn either; tracking changes on a file-by-file basis isn't usually the right abstraction for the way I work.) DCVSs are relatively new, as somebody else pointed out, and in time they will probably have better interfaces.

Yeah, that must be why so many of them use no version control at all...

I agree that the VCS to use is the one that your designer is willing to use. I just think that there's no reason why designers should necessarily want to use Subversion over a DVCS... except that, as a more mature tool, Subversion has a better selection of interface alternatives and a larger installed base.

It's literally the same argument.