Why opting for Git was a natural choice | Hacker News Reader

Why opting for Git was a natural choice

kissflow.com

13 pointsmataug45 comments

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.

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

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.

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.

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

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.

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

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.

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.

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?

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.

> 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

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.

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.

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

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

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.

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

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

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

magit (https://github.com/magit/magit) is unequivocally better than the Git CLI if you use Emacs.

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.

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

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

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.

I doubt if any tool can ever support all the advanced features of GIT like its plumbing commands.

Even a feature like rebase is which is fairly understandable on the CLI, becomes difficult to use on a GUI

I would assume that being able to work offline and not depend on a central repo is enough of a benefit anyhow

I don't this is really a killer feature in this age of always connected devices.

If you've ever tried to get a decent connection on a train through England on a particular network, you'd disagree :)

That is a special and unique circumstance. One can definitely manage time so to not work while travelling.

Yeap, adjusting my life to my VCS tool is perfectly reasonable ;)

If you put it that way, obviously no,but if you think about it as adjusting how you work with the availability of an internet connection, It seems more reasonable :-P

But the point is that, with git, I don't have to do that! :D

(though we actually use Bazaar where I work, but it's distributed all the same)

(Replying again because apparently I can't reply to your new comment) - It's not a 'special circumstance' in anyway shape or form. In an ideal world, we'd always be connected. But when it comes down to it: We aren't at all just yet.

I can't afford to not be able to work when my internet connection drops. What if you have a powercut? What if you are on a flight? What if your network goes down?

As I said these are quite specific to a few people who need to work while travelling. I live in India, I face this all the time, but I overcome this by effective time management.

Well travelling isn't the only circumstance. I just can't find any situation where not being able to work without an internet connection is a good thing.

Also: You have to deal with a central repo. What if that goes down? What if that corrupts? Single point of failure and all.

Reply on news.ycombinator.com