No Joel, is right. The Beanstalk goal mentioned in the linked article "Bring version control into the development process for those who don’t use it" is better served by Git, Mercurial, BZ. All of which make easier for two developers (a small sub-team) to share code without needing a server provisioned.
I hesitate to say this because I actually have an anti-subversion rant in the works, but I think he makes a good point here.
For any develop who is at all serious about their craft, it's absolutely insane to go on using a crippled tool like subversion. However if you have a team of talentless monkey coders mixed with a generous helping of non-technical asset producers (designers, copywriters, etc), then modern VCS won't really give you any compelling benefit, so you are likely better off taking the better tooling.
In the long run Subversion would be better off if they just rewrote it on top of git plumbing, but barring that, it's not necessarily true that everyone has much to gain from modern VCSes.
I tried to like Subversion for quite a long while (any improvement on CVS would be good). In the end the main differences from CVS were. 1: a repository that (at the time) you could not delete "oops I checked in a DVD" from. 2: an Eclipse module that broke during most Eclipse updates.
When svnmerge.py inevitably yaks all over yet another branch we're trying to merge to a release candidate after a rebase or two, I'm only barely capable of figuring out how it got confused and how best to recover, and the rest of my team (experienced developers all) isn't even as good at it as I am. I hear 1.5 with merge tracking isn't that much better.
svn is an extremely leaky abstraction, and just not a reliable enough tool to unleash on the people you're describing. Fortunately we're switching Real Soon Now(tm).
The difference is that you can't do anything without that repository - branching, merging, stashing, diffing, commiting, etc.
In Git, every copy of the code is a repository. If you and a friend are on a train working on code hosted in an SVN repository, you have to jump through hoops without internet access. With Git, you can clone your branch onto a USB key, and then the other person can pull your changeset from that repo. Once you have internet access, either one of you can push the relevant changes to the origin server, or anywhere else for that matter.
You can create an SVN repo anywhere, but everyone has to use the same one. With Git, anyone can use any repo, and they can all interact.
Comments
No Joel, is right. The Beanstalk goal mentioned in the linked article "Bring version control into the development process for those who don’t use it" is better served by Git, Mercurial, BZ. All of which make easier for two developers (a small sub-team) to share code without needing a server provisioned.
I hesitate to say this because I actually have an anti-subversion rant in the works, but I think he makes a good point here.
For any develop who is at all serious about their craft, it's absolutely insane to go on using a crippled tool like subversion. However if you have a team of talentless monkey coders mixed with a generous helping of non-technical asset producers (designers, copywriters, etc), then modern VCS won't really give you any compelling benefit, so you are likely better off taking the better tooling.
In the long run Subversion would be better off if they just rewrote it on top of git plumbing, but barring that, it's not necessarily true that everyone has much to gain from modern VCSes.
I tried to like Subversion for quite a long while (any improvement on CVS would be good). In the end the main differences from CVS were. 1: a repository that (at the time) you could not delete "oops I checked in a DVD" from. 2: an Eclipse module that broke during most Eclipse updates.
When svnmerge.py inevitably yaks all over yet another branch we're trying to merge to a release candidate after a rebase or two, I'm only barely capable of figuring out how it got confused and how best to recover, and the rest of my team (experienced developers all) isn't even as good at it as I am. I hear 1.5 with merge tracking isn't that much better.
svn is an extremely leaky abstraction, and just not a reliable enough tool to unleash on the people you're describing. Fortunately we're switching Real Soon Now(tm).
> without needing a server provisioned.
or they could use beanstalk, i suppose?
Yes, but with git, mercurial and bzr you can sink with a USB key on a train (w/o wifi or cellular network).
Subversion doesn't require a server either. You can create a repository anywhere.
The difference is that you can't do anything without that repository - branching, merging, stashing, diffing, commiting, etc.
In Git, every copy of the code is a repository. If you and a friend are on a train working on code hosted in an SVN repository, you have to jump through hoops without internet access. With Git, you can clone your branch onto a USB key, and then the other person can pull your changeset from that repo. Once you have internet access, either one of you can push the relevant changes to the origin server, or anywhere else for that matter.
You can create an SVN repo anywhere, but everyone has to use the same one. With Git, anyone can use any repo, and they can all interact.