Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bye Bye SVN, Hello Git

engineering.secondmarket.com

Post reply on HN
Print view View original

21–30 of 64 posts

Re: Bye Bye SVN, Hello Git

#21

Post by MBlume »

dneb7 wrote: post #11
astrodust wrote: post #6

Earlier quoted context omitted.

I was wondering if there was something new in here. Instead it's a tale of a company that's been living under a rock for the last four years.

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if…

Simple difference: in svn, until you're ready for other people to see your changes, you have to leave them uncommitted. In git, you say "well, I just refactored function X, let's throw that in a commit before I do anything else, and if I have to revisit it, I will"

I've never had to use svn myself, but it's this aspect that's always sounded positively crippling to my workflow

Re: Bye Bye SVN, Hello Git

#22

Post by solutionyogi »

compay wrote: post #3

It's 2012, not 2008. Why is the #2 story right now about a company that switched from SVN to Git?

It only shows that there are many development shops who have not migrated to a more powerful DVCS (either git or mercurial) and we ought to spread word about how inadequate centralized version control systems are.

Re: Bye Bye SVN, Hello Git

#23

Post by leetrout »

Osiris wrote: post #19

I just recently switched to Git after joining a new company. The team I'm on was just in the process of switching from SVN to Git, so we were all spending a lot of time online in Pro Git as well as researching various workflows. I think that we're still not fully taking advantage of Git because the other members of the team tend to commit and push all the time (so the code is backed up) but that makes rebasing and sq…

Do you have an anecdote about why having more commits have made rebasing / squashing difficult? Is it just that team members are pushing their numerous changes to the central repo? I'm wondering if I'm missing something because I never squash commits...

Re: Bye Bye SVN, Hello Git

#25

Post by luser001 »

solutionyogi wrote: post #15
dneb7 wrote: post #11

Earlier quoted context omitted.

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if…

Yes, git is THAT MUCH BETTER. I wish I had time to get in all the details about why git is better but I will leave you with two questions to ask your existing version control system: 1. How fast is your version control system? Unless you have tried git, you will not realize how painfully slow SVN (or any other VCS which has to talk to server) is. 90% of my git operations take less than a second. Now, you may say that…

Yes, SVN can handle renames. And maintain history across renames.

Btw, SVN supports partial checkouts (git doesn't). Which I use regularly on a gigabyte repo.

I use git regularly for all my hobby projects (mainly because 'git init' seems way simpler than the equivalent svn command), and I might even start a company off on git, but I'll never claim that SVN is obviously a bad way to do things.

Re: Bye Bye SVN, Hello Git

#26

Post by justsomedood »

dneb7 wrote: post #11
astrodust wrote: post #6

Earlier quoted context omitted.

I was wondering if there was something new in here. Instead it's a tale of a company that's been living under a rock for the last four years.

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if…

Even at that, branching isn't hard at all on Subversion. I know that before 1.6 it was more cumbersome, but making a branch for my work and committing a lot of small changes and then merging back when done isn't hard.

There's also the benefit of being able to checkout just one folder of the project wherever you want without having to keep the same folder structure as the source project. I understand git is able to do a "sparse" checkout now, but the parent source folder structure is checked as well.

Re: Bye Bye SVN, Hello Git

#27

Post by montecarl »

solutionyogi wrote: post #15
dneb7 wrote: post #11

Earlier quoted context omitted.

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if…

Yes, git is THAT MUCH BETTER. I wish I had time to get in all the details about why git is better but I will leave you with two questions to ask your existing version control system: 1. How fast is your version control system? Unless you have tried git, you will not realize how painfully slow SVN (or any other VCS which has to talk to server) is. 90% of my git operations take less than a second. Now, you may say that…

Do you care to elaborate on point #2? In svn I can do "svn mv" to rename files. I don't see how this is more difficult than just "mv". Maybe the history of file renames is somehow more easy to follow in git? If I run "svn log renamedfile", I can see the history across file changes.

Re: Bye Bye SVN, Hello Git

#29

Post by elliottcarlson »

compay wrote: post #7
recursive wrote: post #4

Earlier quoted context omitted.

I think there are a lot of people that use subversion.

At the risk of sounding like an elitist hipster hacker, the core audience of this site comes here looking to read articles about innovation, not staid, conservative companies slowly transitioning to established and proven technologies.

A common issue, especially with fast paced startups, is technical debt. This debt can show itself in various ways, and the underlying technology that one uses could be one of those debts. SVN was the popular choice in version control for a long time, and it wouldn't surprise me that there may have been startups that chose this because of comfort-ability in the technology, which has now become a technical debt that will need to be taken care of.

Just because you are an elitist hipster hacker, doesn't mean that this issue will only pertain to staid, conservative companies.

Re: Bye Bye SVN, Hello Git

#30

Post by figglesonrails »

solutionyogi wrote: post #15
dneb7 wrote: post #11

Earlier quoted context omitted.

Under a rock? Is git _that_ much better? I used to read about how it didn't need a central repository, yet this article, and github, seem to indicate everyone ultimately wants/needs a central repository. So git is worth switching just for branching/merging superiority? Maybe I don't do it enough, but svn has never let me down. Or maybe I'm not on a large enough dev team? Guess I'm really just trying to figure out if…

Yes, git is THAT MUCH BETTER. I wish I had time to get in all the details about why git is better but I will leave you with two questions to ask your existing version control system: 1. How fast is your version control system? Unless you have tried git, you will not realize how painfully slow SVN (or any other VCS which has to talk to server) is. 90% of my git operations take less than a second. Now, you may say that…

I use SVN at home and in a 9-5. It's works fine.

1) Fast enough? I have tried git. It's pretty cool, but the difference between 5 seconds and 1 second is minimal at best to me. I don't think I've found myself dying for a faster SCM, though I usually make maybe 1 - 5 commits per day. Git on Win32 is meh compared to git on Linux, so that doesn't really convince me any further either. Git is also a PITA to compile on !Linux using !gcc, because heaven forbid we write using ANSI/ISO C.

2) Yes? I can do renames, but strictly speaking it is not an atomic "rename" operation. I don't particularly care about rename history, and I'm not really sure why others do, but I guess if I tried I could make up a use-case for it. Still, it wouldn't be a selling feature for me, that's for sure.

It seems strange to me that you take the time to tell us that "git is better", like we're comparing O(n) to O(log(n)) algorithms. Different workflows, projects, and organization structures have different needs. It seems hopelessly naive to simply assume everyone's needs are best fit by git, and git alone.

How about this: I want to tell, given two revision numbers in the mainline branch, which came first? In SVN, it's pretty simple. In git? Well, first open a terminal...then ...argh. As release manager, it's kind of annoying. Simple use case: is 2aa8aca05357004d4418807c06f53d81517bc629 before or after e8d0555ce401b6acb0f225aa0263e9b72136347d? Did e8d0555ce401b6acb0f225aa0263e9b72136347d make it into the build given that 5b5c73ceaa442bafff08b4470aad3ff276be94e3 was the final commit before the cut-off?

I might waste 5 seconds opening a terminal window or tab, 30 seconds finding, copying, and pasting the revision numbers, then a second or two determining the answer. This, to me, is not a productive use of my time when revision numbers simply tell me what I need to know. All of that magical time git just saved me might have just been absorbed or gone into time debt.

Post reply on HN