Comments on “ Subversion or Git ”

Subversion or Git

2008-05-01T05:07:20-04:00

Thanks, João. It’s at the top of my list. Once I get a minute to migrate one of my existing projects over, I’m going to start learning. I have an 18 hour flight coming up and it would be nice to be able to develop and commit. My goal is to transition something by then so that I can work during the flight.

Subversion or Git

2008-04-30T22:55:45-04:00

@Rob

I didn’t really understand all the fuzz about DVCS. Not until I got to use it regularly.
We use SVN at work, but I’m using Git-SVN myself. Now that I got the hang of Git’s branching/merging, I realize how much SVN branches suck. I no longer have to remind myself what exactly I’ve been doing, and usually all I need to do is to “git merge my_branch”.

It’s well worth the try. Nobody really sees you’re using Git-SVN. It’s transparent.

Subversion or Git

2008-04-30T20:06:10-04:00

@Dustin –

I don’t think branches are particularly difficult, but since most work occurs on the trunk I tend to move off on a branch for those efforts that will impact the experience of other developers working on the trunk.

If I’m reading you right, one of the key differences between our experiences is that, using Svn, I tend to feel like I have to think ahead and identify those changes that should be branched before I start working on them. I don’t suppose that’s entirely accurate, but to the extent that I feel that way, I guess branches are more difficult.

I’m not sure that answers your question very well, but maybe it’s a start.

Subversion or Git

2008-04-30T19:39:53-04:00

You mentioned you use branches for “Developing large, destabilizing features, and Maintenance of current releases.” Is that because they’re difficult to use in your tools, or do you just really feel like it’s the right thing to do?

I use branches when I think, “Huh, I wonder if this will work?” Or, “Note to self, we’re going to upgrade soon and I’ll have to do this a different way.” Or, “Ugh, none of those changes I made are ready to go to production yet, I need to go back and slice these last few changesets into a branch and work on another feature.”

Small distances can seem very far away when you have to walk them.

Subversion or Git

2008-04-16T10:18:52-04:00

Since I seem to be posting my source control link feed here, here’s another good “why svn is suboptimal” post: http://blogs.sun.com/smarks/entry/why_i_don_t_like .

Subversion or Git

2008-04-09T05:26:06-04:00

No shit? I use Assembla’s Svn+Trac offering for several personal projects (including this site). I didn’t realize that they had a Git offering. I thought I actually looked a while back, but either they didn’t have it then or I didn’t see it. I’ll definitely be checking that out.

Thanks.

Subversion or Git

2008-04-08T23:47:31-04:00

Oh, and I’ll admit to some github jealousy as well, that’s a pretty sweet service.

Subversion or Git

2008-04-08T23:46:27-04:00

I’ve never even installed git, I’ve been playing around with mercurial, mostly just because I like that it’s in python. I’ve liked the idea of distributed source control for a while, but am just now getting up to switching momentum.

You can create a project at assembla , then go to admin/tools and do “add git & trac” to get a git repo and a trac set up for you; I did it with mercurial and it was pretty easy.

Subversion or Git

2008-04-08T18:55:53-04:00

@Bill Mill – As long as you’re providing good information, monopolize away. :-) As Git’s leading evangelist (that I know), do you (or anyone you know) have any invites to the GitHub beta? I wouldn’t mind seeing what all the fuss is about first hand.

Subversion or Git

2008-04-08T18:51:26-04:00

Sorry to monopolize the thread, but Ryan Tomayko also just weighed in .

Subversion or Git

2008-04-07T15:16:49-04:00

@Chad –

And offshoring, although that could be considered a specialized type of telecommuting. I have a team in India, but I guess my point is that even with that team to consider, Git seems to solve problems that I don’t have. I was wondering what, if anything, I was missing. If I can find a free service offering Git hosting, I may move a project over and try it out in order to get some hands-on experience.

Subversion or Git

2008-04-07T15:11:23-04:00

The version control realm is certainly expanding and diversifying. Seems like this is a direct result of the growing number of decentralized development teams brought about by the growth of the open source community and an increase in telecommuting.

Subversion or Git

2008-04-06T13:48:58-04:00

Well, interesting how these things happen in bunches. Jeff Atwood just posted on source control, and a lot of his commenters suggested DVCS to him. Then, Bill de Hora posted on why he prefers DVCS, including a couple reasons we talked about and one we didn’t.

Subversion or Git

2008-04-06T11:31:44-04:00

@Bill – True. I didn’t mean to imply that I think merges should be done daily regardless of current state. I was responding to “typical” development where lots of small changes are being made. Iterative improvements, if you will, rather than new features or larger scale changes.

I’ll check out the tutorial you linked. It’s always interesting to see how others are using tools within their daily workflow. Thanks.

Subversion or Git

2008-04-06T10:57:25-04:00

Well, I think merges should take place once a feature is complete. Another nice thing about the new breed of source control is that it makes it very easy to create email patchsets, which are perfect for code review before merging into the trunk on the shared repo.

It was enlightening for me to read this tutorial about how the SymPy team uses mercurial to fix bugs and review code before checkin to the main repository.

Subversion or Git

2008-04-06T08:13:34-04:00

Fair enough. You make some good points or, more accurately, put some personal experience behind some that I had already seen and what you say makes sense. I wasn’t aware of the branching pain you’ve had. I work primarily on the trunk and only branch for:

Developing large, destabilizing features, and
Maintenance of current releases

As a result, my merging needs are minimal. If they became more sophisticated, then I might have to look elsewhere.

I do like the idea of offline use (even though I feel like my entire life is spent online), but I find it hard to wrap my mind around how it could work in a team environment. Maybe installing a process of daily merges with the “king” repository is all it would take.

Subversion or Git

2008-04-06T00:01:56-04:00

I got fired up there and remembered a fourth reason while I was writing; that should be “the reasons are four-fold”

Subversion or Git

2008-04-06T00:00:45-04:00

Well, I don’t currently use Git or Mercurial, though I just opened up my first mercurial repo and plan to learn how to use it.

The reasons for it, in my case, are threefold:

Reasonable branching and merging. Branching in svn is slow, but the real killer of it is that svn doesn’t remember when you branched. This means that, when you go to merge, you have to manually go back and recover the version at which you last merged, create a diff, and patch it back into the main branch. And god help you if you needed to merge just a few small changes from trunk back into a branch, and then a branch back into trunk. Who knows what was in there and what wasn’t? I’ve had to check, manually, thousand-line diffs and more or less click and pray. It’s a bad scene, and hacks like eazysvn are just evidence that it needs to be fixed.
Offline use. I was offline for a few days there, and not being able to check in was extremely frustrating. It also led to a huge checkin once I got back online, which defeats the purpose of version control in the first place. This is compounded by:
Committing chunks. Svn always assumes that you want to check in all of your changes to a file. Git/Hg, on the other hand, will (if you want) ask you about each change and whether you want to commit it, and make seperate patches for each chunk that you want to commit.
Svn is slow-moving. It takes forever to get changes into the main builds of svn; I found and hit a bug with locking that had existed with a fix for over a year that just hadn’t been put in yet.

All of these are leading me to try mercurial. As for accountability, in my opinion this is already solved by process and using decentralized source control doesn’t affect it much. Having a developer who only checks in to a local repo is exactly the same as having a developer who never checks in his code.