Hacker News Reader

The main issue we faced wasn't really branching, but the merging that needed to happen after that. It was a real pain.

Here is a detailed explanation on why it sucks http://stackoverflow.com/a/2472251/492561

Were you using an old version of svn? Merging has gotten a lot better starting with 1.5.

I don't agree with most of the points in that post. Let's go through them:

1. "It doesn't have merge tracking." That was true at one point: manual merge tracking was indeed a miserable, error-prone experience. But automatic merge tracking was introduced five years ago, so this criticism is no longer relevant.

2. "You have to see everyone's experimental branches." This is not so: you can use any directory hierarchy you like, so you can cordon off experimental branches any way you want. A common workflow is to have a directory per engineer, in which case you don't see their private branches until you go poking around in their directory. And storing private branches on the server (where they get backed up) can only be a good thing.

3. "git better handles sending patches around through uniquely identifiable revisions." Here "uniquely identifiable" means across separate repositories. This is only relevant in a truly distributed system, where there really is no central server containing the truth. For the truly distributed case, git is clearly to be preferred. But most teams really do use a central server. Like github!

Overall, I think the answer is: it doesn't matter much. git and svn in their modern forms are both very powerful and capable tools. There's a few cases where one excels the other: git is better if you have multiple repositories, while svn is better if you have a large quantity of images or binary files. But for most teams, either tool is more than adequate, and it comes down to experience or personal taste.

Okay how about this,

There is not a Central Server UI for SVN that comes close to Github !

Rebase is very difficult to out-right impossible.

> Subversion uses copy-on-write when creating a branch, so it is not expensive

It doesn't matter what the server does, it's relatively slow on the client to either switch to or checkout a branch.

With git, you typically have a single checkout of the repo. But with svn, it's natural to have separate checkouts of each branch you care about, in separate directories. So a typical "switch" in svn is not a switch at all: you just start working on files in a separate directory, or even simultaneously on two separate checkouts (which is more awkward in git).

I use and like git, but multiple checkouts is one aspect of the svn workflow that I miss.

You're making my point for me. In typical Subversion client usage the server's CoW optimisations mean nothing.

If you have to check out each branch you make, using Subversion gets really slow, really quickly.

There's no problem with having multiple clones of a git repository on a single machine.

On the plus side, you can have multiple local branches side-by-side with svn easily, which is much easier to work with for beginners as they can just view and compare the trees in the filesystem. With git, such a setup requires more understanding on how to make a local clone instead of fetching the full history from the server multiple times.

Fetching the full history in git is often less data than a checkout in svn.

Also you could just copy the folder.

Edit: git-new-workdir looks like it makes things convenient.

Branches may be cheap in SVN, but merging is not[1]. This means that from the point of view of a developer - branching isn't cheap.

[1] I believe SVN has improved their merging code in recent years, but this happened after I switched to git.

Neither it is in git. See the discussions about how rebased commits are often preferred.

"Subversion uses copy-on-write when creating a branch, so it is not expensive"

Agreed - it's a constant-time operation according to the documentation, and took about 5 seconds for me to branch a copy of thousands of small files.

Git does have some useful features (e.g. committing part of a file), but a change of VCS will not magically solve all your problems if the flaw is with your workflow, code or internal communications.

If your working tree is large it will take a long time to copy it, no way around that.

I do understand SVN branching/merging is expensive when compared to GIT, But in GIT day to day activities like(commit, push and pull...) is expensive than SVN.At the end we have great eco-system for SVN. what about GIT?

> in GIT day to day activities like(commit, push and pull...) is expensive

No.

http://thkoch2001.github.io/whygitisbetter/#git-is-fast

> At the end we have great eco-system for SVN. what about GIT?

Aside from the great command line tools, all the IDEs I've tried have integration for git, and all the bug trackers / project management things

How is commit, push, and pull more expensive in git than SVN? In git commit, diff, branch, merge are local operations. The server only needs to be contacted on push and pull.

I didn't mean for normal operations. when we flow a standard workflow in GIT then it becomes expensive.

This teething trouble is faced with any tool that needs to be used.

In a short period of time everyone gets up to speed on how things work, and it will all be back to normal. Though this depends on the willingness to embrace the change.

Branching in SVN takes many times longer than git. So it feels much more expensive.

Creating a copy of the working tree is not cheap at all.