4 ms·

I think this article does not do the svn workflow justice. Svn was designed with the inherent assumption that the context of a developer within any single code

I think this article does not do the svn workflow justice. Svn was designed with the inherent assumption that the context of a developer within any single codebase would be linear This may be how the engineers in question used svn, but that's certainly not how svn was designed! Creating a branch in Subversion is not difficult or expensive. It's natural for each engineer on a team to have a separate svn directory containing "private" branches. If engineers are committing unstable code to the trunk, they're doing it wrong. Git branching is also cheap and quick, unlike svn in which a branching creating a new copy of code. Git also preserves history when branching, unlike Svn. Subversion uses copy-on-write when creating a branch, so it is not expensive. Subversion also records the branch event in the file's history. It sounds like the team had a flawed understanding of svn, and was using a terrible workflow. The benefits of the switch are not due to git, but to investing actual time learning a scm tool. That same time invested into learning svn would have paid equal dividends.

taspeotis 13y ago
> 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.
- raimue 13y ago
  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.
  - Dylan16807 13y ago
    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.
- millstone 13y ago
  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.
  - richardwhiuk 13y ago
    There's no problem with having multiple clones of a git repository on a single machine.
  - taspeotis 13y ago
    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.
pwaring 13y ago
"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.
- Peaker 13y ago
  If your working tree is large it will take a long time to copy it, no way around that.
glenjamin 13y ago
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.
- silon3 13y ago
  Neither it is in git. See the discussions about how rebased commits are often preferred.
mataug 13y ago
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 http://stackoverflow.com/a/2472251/492561
- millstone 13y ago
  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.
  - mataug 13y ago
    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.
vivekmadurai 13y ago
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?
- lmz 13y ago
  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.
  - vivekmadurai 13y ago
    I didn't mean for normal operations. when we flow a standard workflow in GIT then it becomes expensive.
    - mataug 13y ago
      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.
- Shish2k 13y ago
  > in GIT day to day activities like(commit, push and pull...) is expensive No. http://thkoch2001.github.io/whygitisbetter/#git-is-fast 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
rmc 13y ago
Branching in SVN takes many times longer than git. So it feels much more expensive.
Peaker 13y ago
Creating a copy of the working tree is not cheap at all.

taspeotis 13y ago

> 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.

raimue 13y ago
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.
- Dylan16807 13y ago
  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.
millstone 13y ago
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.
- richardwhiuk 13y ago
  There's no problem with having multiple clones of a git repository on a single machine.
- taspeotis 13y ago
  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.

pwaring 13y ago

"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.

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

glenjamin 13y ago

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.

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

mataug 13y ago

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 http://stackoverflow.com/a/2472251/492561

millstone 13y ago
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.
- mataug 13y ago
  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.

vivekmadurai 13y ago

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?

lmz 13y ago
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.
- vivekmadurai 13y ago
  I didn't mean for normal operations. when we flow a standard workflow in GIT then it becomes expensive.
  - mataug 13y ago
    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.
Shish2k 13y ago
> in GIT day to day activities like(commit, push and pull...) is expensive No. http://thkoch2001.github.io/whygitisbetter/#git-is-fast 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

rmc 13y ago

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

Peaker 13y ago

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