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.
Bye Bye SVN, Hello Git
51–60 of 64 posts
Re: Bye Bye SVN, Hello Git
#52Earlier 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…
Re: Bye Bye SVN, Hello Git
#53Earlier 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…
Re: Bye Bye SVN, Hello Git
#54Historically 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.
Re: Bye Bye SVN, Hello Git
#55Earlier 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…
(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
#56Earlier 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...
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
#57It's 2012, not 2008. Why is the #2 story right now about a company that switched from SVN to Git?
Re: Bye Bye SVN, Hello Git
#58Earlier 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.
Re: Bye Bye SVN, Hello Git
#59I personally discourage the use of squash, I think that everyone benefits with more granular commits. Is this not common practice?
Re: Bye Bye SVN, Hello Git
#60It's 2012, not 2008. Why is the #2 story right now about a company that switched from SVN to Git?