Hanselminutes Podcast 108 - Exploring Distributed Source Control with Git
My one-hundred-and-eighth podcast is up. In this episode I sit down with Robby, Gary and Andy from Planet Argon, a local Rails shop in Portland, OR, and talk about their experience as they move from Subversion to Git for their source control.
Links from the Show
- Download: MP3 Full Show
- ACTION: Please vote for us on Podcast Alley! Digg us at Digg Podcasts!
If you have trouble downloading, or your download is slow, do try the torrent with µtorrent or another BitTorrent Downloader.
Do also remember the complete archives are always up and they have PDF Transcripts, a little known feature that show up a few weeks after each show.
Telerik is our sponsor for this show.
Check out their UI Suite of controls for ASP.NET. It's very hardcore stuff. One of the things I appreciate about Telerik is their commitment to completeness. For example, they have a page about their Right-to-Left support while some vendors have zero support, or don't bother testing. They also are committed to XHTML compliance and publish their roadmap. It's nice when your controls vendor is very transparent.
As I've said before this show comes to you with the audio expertise and stewardship of Carl Franklin. The name comes from Travis Illig, but the goal of the show is simple. Avoid wasting the listener's time. (and make the commute less boring)
Enjoy. Who knows what'll happen in the next show?
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
I haven't been getting as much of my Hanselman 'fix' lately, after moving from .NET to Ruby, full-time, about 6 months ago (and Windows to Linux over a year ago, after literally a lifetime on Windows).
Dunno how your general audience feels, but I love the non-MS/.NET-specific Hanselminutes episodes to give me an excuse to listen :P
By the way, people are doing all kinds of neat things with git ... for example, TicGit is a super neat ticketing system built right into your git repo! Some people are using repos for their blogs, as a kindof database ... I like using branches for deployment (checkout old branch to rollback) ... some of these things aren't necessarily specific to git, but it's certainly caused a bit of a craze!
Anyway, I'd be interested in seeing git gain more ground on Windows (like not having to use cygwin).
However, I'm surprised you didn't talk about the performance and disk space requirements for storing the entire repository's change history on a developer's PC. For example, if I were to start using Git on a large enterprise application with 6 years of revision history, would "get latest" take seconds or minutes? If the codebase itself is nMB, what multiple of n would be required for the Git repository?
Scott, great show, as always. I think the "word from the sponsor"-section really shows you professional touch on everything you do. The first podcast with the commercial-break was a disaster! That Frankling-guy tries to do the trademarked slipstreamed commercial, which is to say the least, despicable.
"So, what's your thought on Git... by the way, how do you create Web 2.0-applications with 1.0-technologies?" Crazy stuff. Like I said, your approach is much better and more professional.
Looking forward to the next show!
I still have yet to hear why merges are so much better and easier in GIT. From what you explained it sounds the same as what you do with subversion? And, with subversion 1.5 adding mergetracking it will even be easier soon including selective revision merging.
Please someone tell me what makes merging so much better in GIT?
One of the guys in the podcast mentioned that GIT has one location where it stores the DB so that your working copy is nice and clean - unlike Subversion where you have .svn (or _svn) directories within *every* working copy directory. Well, that is planned as a future feature of Subversion. I'm sure if enough of us thought it was a problem, we could get it's priority raised.
So the other big thing about GIT seams to be the distributed nature of the repository. Doesn't SVK do that?
I really like Subversion, I think it's great. There is room for improvement though - especially for Windows users. How about integration directly with IIS rather than into Apache? How about a repository-level configuration option for case insensitivity so that '/trunk/myfile.txt' and '/trunk/MyFile.TXT' are the same file? (Not everybody in the world is running UNIX, you know!) Now I know that I've griped about Subversion a little here, but I can't imagine that these particular issues are going to be any different with GIT since it has pretty much the same heritage.
Anyway, Scott. You mentioned that you're getting the Team System guys onto Hanselminutes. How about getting the SVN guys on so they can have right of reply wrt GIT?
One part I am having a very hard time with is the full repository on everyone's machine? How does security work in that world? What about very large code bases? For example our total repository size is well over a tarabyte and I am sure most people do not have that much disk space on their machines.
As always I love learning about new things on hanselminutes.
In fact, when I tried importing just the last version, it worked fine, but the first time I git svn dcommitt'd, it then fetch'd all past versions.
@Chris: git repo's are waaay small. They're like gzip, in that they recognize files (or portions of files?) that are identical between versions. Your 1tb repo might become 100mb if you do a full fetch then repack. Seriously.
@Damian, @Bob: I might still stay with svn, once v1.5 comes out, but git merges effectively push all changes from the merged branch into the mergee, *individually*, at the time of the original change. The individual commits are intact, in other words. In contrast, in svn and cvs, you have a single "merged trunk to this branch" commit. Not as natural.
I have a 438MB svn repo which I've imported into git. The .git repo is 137MB. So that's about 1/3 size.
While GIT may work for small project or orgs I am just not sure how it scales to something very large.
Thanks for the response.
My test, which got the 1/3 ratio, was for a full import of every version.
That said, I haven't tried it with a 300m file repo ... I have no idea if it scales that large. That seems insanely large .... I'm amazed svn could handle it!
I wonder if it is practical to use it on Windows using Cygwin;
and if it is, how is the overall experience compared to svn? (considering tools, integration with VS, ...)
Git has a lot of interesting use cases outside the limited domain of "svn/cvs replacement". It's worth reading http://www-cs-students.stanford.edu/~blynn/gitmagic/ to get an idea of other ways it can be used (e.g. as a generic undo mechanism for arbitrary files like configs in /etc).
@Bahador: there's a git package built into cygwin. There's also a more regular native port using mingw, but I haven't used it. No Tortoise equivalent yet. :-(
Comments are closed.
I hope there is a TortoiseGit in the works, because one of the best things about subversion is how great and effortless TortoiseSVN makes it.