Live data from Hacker News

Bye Bye SVN, Hello Git

engineering.secondmarket.com

51–60 of 64 posts

Re: Bye Bye SVN, Hello Git

#51

Earlier quoted context omitted.

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.

With git, I don't have to tell it that I renamed file. It can even figure out if I moved the file from one folder to another. And with git, I can see the complete history without worrying about the fact that the name might have changed in the past.

Re: Bye Bye SVN, Hello Git

#52
post #33

Earlier quoted context omitted.

I've only just made the switch. Like most people I was stuck with SVN due to my employer using it, and refusing to update. Now I'm freelance I've had the time to put into learning Git and I'm glad I did, but the point is there are still a lot of people using SVN, some of whom will switch to Git in the future, and posts like this can be very useful to them.

> and refusing to update. How true this is. I spoke with one sysadmin who told me that even if 100% of the developers were using git-svn he would never allow git as the official location to store code on the servers and it must be pushed back to svn. I am not sure how to respond to people like that. Edit: When pressed for more details it was clear that he was happy with his svn server setup and didn't want to change…

Good admins resist change. Great admins can tell you why.

Re: Bye Bye SVN, Hello Git

#53
post #10

Earlier quoted context omitted.

Sure, and I'm one of them. It's not exactly startling news in 2012 that a lot of people prefer the git/hg model. Hell, I prefer it myself! But I've got a complete svn ecosystem set up here, with 44 projects in a single svn repository, automatic offsite backups, and hundreds of checked-out directories spread across five (or more?) computers with five distinct operating systems. As far as I can see, the one-time costs…

I'm one of them as well. I'd also love to use git. The issue I have we it is that I feel like the "port" to Windows was more of a crowbar sort of operation rather than a well thought out plan to make a program cross-platform compatible. Install TortoiseSVN. Done. Install TortoiseHg. Oh it needs something else. What's it called? Ok. I need msysGit. I'll get that. Ok, they're all in beta? Whatever I'll just get one. Wh…

The guide at github[0] is pretty easy to follow. I've done it on some of my fellow students' pc's a couple of times during a project, but most of them switched to Ubuntu after a couple of weeks.

[0]http://help.github.com/win-set-up-git/

Re: Bye Bye SVN, Hello Git

#54

Historically with SVN, branching was skittish. Really? How? I've always found Subversion branching to be painless, reliable, fast enough, and merges often go flawlessly, and it's really not been that hard to resolve merge conflicts.

Branching with SVN requires creating a separate copy of the entire repository, effectively. It rapidly becomes unwieldy with larger projects.

Re: Bye Bye SVN, Hello Git

#55
post #10

Earlier quoted context omitted.

Sure, and I'm one of them. It's not exactly startling news in 2012 that a lot of people prefer the git/hg model. Hell, I prefer it myself! But I've got a complete svn ecosystem set up here, with 44 projects in a single svn repository, automatic offsite backups, and hundreds of checked-out directories spread across five (or more?) computers with five distinct operating systems. As far as I can see, the one-time costs…

I'm one of them as well. I'd also love to use git. The issue I have we it is that I feel like the "port" to Windows was more of a crowbar sort of operation rather than a well thought out plan to make a program cross-platform compatible. Install TortoiseSVN. Done. Install TortoiseHg. Oh it needs something else. What's it called? Ok. I need msysGit. I'll get that. Ok, they're all in beta? Whatever I'll just get one. Wh…

I assume you meant TortoiseGit? Otherwise, I think I spot the problem.

(Just pointing out because TortoiseHg actually is fairly painless to install if you want to use Mercurial on Windows, and the typo might confuse some)

Re: Bye Bye SVN, Hello Git

#56
post #35

Earlier quoted context omitted.

Anything in particular you would like to know? I have done it twice. First at Trolltech where Qt was moved over (I want to say there are a handful of public blogs on this) and I have helped with a bunch of perforce/git migration/integration at RIM and consulted with various other companies.

Can you describe your largest migration, in terms of users affected and the repository size? Did you experience some of the issues Facebook has? See: http://thread.gmane.org/gmane.comp.version-control.git/18977...

I can't give explicit numbers, but yes I experienced some of the issues Facebook wrote about. This particular problem stems from SVN/Perforce and how they give the user the ability to only checkout part of the repo.

Setup 1 exploites this. This would be movie companies were every version of every rendering is in Perforce. On the server you have easily many times even the size of the desktop hd, and users only grab what they need/want. These companies should stick with Perforce.

Setup 2 came about from laziness. Everything was dumped into the repo with no organization. Converting it to git will require a XXXGB repo which while manageable windows can't handle well. You encounter say dozens of copies of the binary sprinkled around inside of the source directory (not even revisioned, just copied with the version included in the file name). Need a copy of every Windows NT CD's stored somewhere? Why not in the src directory!?! Once you cleanup/split this the src repo goes down to a usable size.

After the above basic cleanup (which honestly can/should have been done in svn/perforce anyway.) the src repo can still be a large size because the src isn't the src for one project, but maybe dozens or hundreds of projects that compile to one binary (or some similar setup such as lots of little binaries that are one product). It is then up to you to decide on how you want to proceed. There are a few different approaches with different pros and cons and situation specific. (And discussing them is really a full blog entry not a random hacker news comment).

I'll leave you with my law about repo size: When every developer in a company is committing to the same branch the odds that a commit will break the build increases as more developers are hired.

Edit: simplified

Re: Bye Bye SVN, Hello Git

#57
post #3

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

That's the beauty of giving the power to the community to decide what is interesting to them. There seems to be a lot of people using older source control solutions and for one reason or another haven't made the move to use a better solution. That's what inspired me to write this post in the first place. We made the move and it improved our lives and I simply wanted people to know about it.

Re: Bye Bye SVN, Hello Git

#58
post #7

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.

As I mentioned in an earlier comment, that's the beauty of giving the power to the community to decide what is interesting to them. I wouldn't describe SecondMarket as a staid, conservative company, we use amazing open source technologies such as Solr, Scala, Akka, mongoDB, etc. in a very agile environment. We also like to think we are changing the way in which the financial markets are working. However svn was one technology we were stuck in the past with and we wanted to share that making such a basic change has made our life better.

Re: Bye Bye SVN, Hello Git

#59
post #24

I personally discourage the use of squash, I think that everyone benefits with more granular commits. Is this not common practice?

We think that a repository with too much noise isn't so useful. When you squash you should use common sense and aggregate the commit comments as you see fit.

Re: Bye Bye SVN, Hello Git

#60
post #3

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

4-year cycle of generations of comp-sci grads re-learning the bleeding edge they were ignoring while they were studying?
Post reply on HN