Why opting for Git was a natural choice

http://kissflow.com/kissu_kissu/git-vs-svn/

by mataug • 13 years ago

13 44 13 years ago

kissflow.com

mataug11• 13 years ago

The gist: The technicalities of moving away from SVN was never a problem for us, It was more of a workflow issue.

I think this should be the real reason anyone should consider moving their codebase from SVN to GIT.

sircausticsoda• 13 years ago

Git sucks. It ruins my process. SVN has great integration with eclipse .

roryokane• 13 years ago

It would be more accurate to phrase that not as “Git sucks”, but as “the EGit plugin sucks”, or, if you must generalize, “Git’s ecosystem sucks”.

mataug11• 13 years ago

I would agree, There is nothing that can beat the Git-cli at least for now.

davvid• 13 years ago

I would disagree with the generalization that "Git's ecosystem sucks", though ;-) Many tools have Git support these days, and supplemental tools around Git are plentiful and quite mature. The Git community is friendly and helpful, especially around the mailing list and IRC.

andyhmltn5• 13 years ago

Why? I personally don't use Eclipse but I'm sure there is a tool out there to provide similar functionality.

mataug11• 13 years ago

Intellij and other IDEs from jetBrains have pretty good GIT integration that works quite well and is similar to the GIT-cli

vivekmadurai3• 13 years ago

If I want to move to GIT, then I should use all the advantages of GIT, I couldn't find single GIT client/plugin that directly supports all the advanced features in GIT including Egit, intellij and others.

millstone3• 13 years ago

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.

taspeotis2• 13 years 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• 13 years 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.

millstone3• 13 years 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.

pwaring• 13 years 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.

Peaker3• 13 years ago

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

glenjamin• 13 years 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• 13 years ago

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

mataug11• 13 years 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

millstone3• 13 years 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.

vivekmadurai3• 13 years 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• 13 years 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.

Shish2k• 13 years ago

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

rmc• 13 years ago

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

Peaker3• 13 years ago

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

tehwalrus2• 13 years ago

The way I handled branching in SVN was to have several checkouts of the same trunk, and run "svn update" to fast-forward before committing (once my patch had passed code review.) Hard drives are cheap, brain cells expensive!

(note, this model works fine when you have a big company machine sat in an office on gigabit LAN to the SVN server - break any of the assumptions there, and SVN quickly deteriorates. I'm not saying git isn't better, just than SVN isn't that bad where I encountered it.)

Peaker3• 13 years ago

Hard drives are slow. Copying a huge working tree to make a small branch makes no sense.

tehwalrus2• 13 years ago

I would just permanently maintain 4 or 5 checkouts of active projects, and rename the containing directories for branch names. I know git is better, I'm just saying SVN can be used in a similar way, if less efficiently.

Why opting for Git was a natural choice

Related Stories