Hacker News Reader

Comment by huherto | Hacker News Reader

To me github is the killer feature of git.

I think svn is easier and more appropiate for a corporate environment.

Really? Git seems like the killer feature of Github to me...

Why do you think that git is inappropriate for a corporate environment? I've been using it in one for a few years now and see nothing wrong with that.

I think the killer feature of git -- which applies to any other DVCS -- is that you're not dependent on github if you're well prepared. There's absolutely nothing stopping you adding redundant remotes so you always have somewhere to push/pull changes and deploy from.

    git remote add <remote_name> url

Yep and that's like managing dns with host files...

svn is fine for very small, highly co-ordinated teams which is rare in a corporate environment. It's decidedly not fine for complex merging, development outside of the private network, or maintaining multiple versions of the same codebase (customer installs) among other things.

Even then, doing without "add -p", "rebase -i", "commit --amend", inplace branches, and various other git features is going to cost you.

the achilles heel of svn is branches cost 100% of the branched repository. even an svn repo with one user can be prohibitively large.

even in a corporate lan environment just pulling down an svn repository can take far too long

Why do you say branches are expensive?

http://stackoverflow.com/questions/2041/how-do-i-create-a-br...

You have to maintain a full copy of the file tree locally per branch, it's a pain that gets worse as your project size grows. With git, switching between branches is near instantaneous.

It is in svn as well (200mb wc switch = 4 seconds).

I worked in an environment with a significantly larger repository, and svn switches were a constant source of frustration.

sorry but that is a very long time. Branching is something I do dozens, if not hundreds, of times a day (creating, checking out, deleting, etc).

svn doesn't fit the sane modern workflow and everything it does can be done by git in a less painful manner. I think the only use case I can think of for svn is a very binary heavy repo that needs global locking.

500MB branch in git - git checkout -b mybranch master == 500MB 500MB branch in svn - svn copy ... == 1GB

Branches cost nothing in svn. I doubt you've used it. svn copy only appends a pointer back to the source rev, much as git does.

i used to use them extensively. unless something has radically changed, they cost nothing in the svn repository but when you pull them down, you have multiple copies on disk which takes double the space because of the way a branch appears like a separate folder in your working copy. am i missing something?

Your working copy has a URL. You can switch it to another URL (a branch/tag) using "svn switch". It only transfers the differences between the two.

You can have two separate copies checked out, but you don't have to.

It is interesting, I have heard several times the comment about svn branches being expensive. But, that is not true, they are checking out the whole branches directory!

Are you checking out all the branches? I mean the actual branches subdirectory? If you do that, it is going to be expensive. But you shouldn't do that. Just checkout the trunk and switch to branches as needed.

Reply on news.ycombinator.com