Version control for solo Mac developers
cocoawithlove.com
cocoawithlove.com
FWIW, I'm using svn or git, together with acunote, for my projects, either solo or with a team.
Just for the record, I've used RCS, CVS, clearcase, SVN, git and mercurial, but for doing solo work fossil beats all of them in simplicity and ease of use (single executable, no setup needed).
Absolutely. For me, the main reason I stayed away from Git as long as I did was the communities stance that the command line is how it should be used. When I downloaded GitX and saw how nice it was I switched immediately.
Once you're used to something so fundamental, it's hard to imagine people won't use it as well :)
Bad attitude in my opinion. At some point they will have to do a costly and complicated migration to a modern system, and that could have been completely avoided by simply using a modern system to begin with.
>There's no need to waste time on a religious war within the church of version control, when there are non-believers who must be shown the light.
The only religious behavior I see here is claiming that a two systems are equivalent when they clearly are not.
Three main reasons:
- windows support is still far from brilliant for git
- even a non-technical user can understand and use tortoisesvn in 2 hours
- SVN revisions are really easy to understand
Don't get me wrong, I'm using git in a lot of places (including my own projects), but most of my non-technical clients are on svn.
EDIT: just so you know, I still know one company (a startup, mind you!) that uses CVS.
It's not that bad, certainly not much worse than SVN itself on windows.
>- even a non-technical user can understand and use tortoisesvn in 2 hours
2 hours? A non-technical person can understand everything about e.g. Git that they're likely to need in less than that.
>- SVN revisions are really easy to understand
Not sure what you mean here. 1783. Is that somehow easier to understand than an equally meaningless hash key? At least in Git you could describe the version by the checkin text.
>but most of my non-technical clients are on svn
I think you're really doing them a disservice with this. As soon as they have any kind of accidental corruption I think you're going to be sorely missing Git's recovery capabilities and ability to mathmatically prove you're working with the version you think you're working with.
In most places centralized is the way to go. It may be unbelievable for the HN crowd, but most developers use only the bare minimum features of version control, and even then only after being forced to. In this scenario distributed version control causes more problems than it solves, not to mention the lack of integration with IDEs.
Yes, that's the real world for ya.
Except that a distributed RCS can do everything a centralized on can. The funny thing is, this is the last argument used by people religious about SVN but even this doesn't stand up. SVN isn't even particularly good at doing centralized revision control. Do you work somewhere that you'll have to be able to prove what was in a given release? SVN can't do that since you can rewrite history with no way of detecting the rewrite. If this is not acceptable you'll have to buy Fisheye.
SVN on it's own isn't useful for much of anything. It's only after applying several other commercial products that you finally get something only substandard.
Like I said, in most cases you are trying to convince developers that don't want to use any kind of version control. They want IDE integration, they won't use branches or any other features (some won't even know what the hell "branches" are), they will only use version control as a means to have a centralize repository for the code.
And they use Windows.
SVN solves the problem. It's either SVN or something worse (CVS and SourceSafe are still widely used).
Version control is a tool. You have a set of requirements and you choose the tool based on those requirements. There is no such thing as "obsolete".
IDE integration makes more sense with file focused systems like ClearCase. With "whole picture" focused systems like SVN, Git, etc., the value of IDE integration is less because you check in whole change sets at once. The only IDE I've ever seen that dealt with this reasonably well was Smalltalk.
>They want IDE integration, they won't use branches or any other features (some won't even know what the hell "branches" are), they will only use version control as a means to have a centralize repository for the code.
DVCS can do exactly this. Set up a hook so that e.g. Git pushes to a central repo on commit. You don't need to teach them about branches or any of that, just give them something simple.
By doing just this much you get automatic local "backups" of the repo and you get vastly better protection against corruption and tampering.
>And they use Windows.
No problem. Mercurial, for example, supports windows very well. Including a Tortoise interface that is (IMO) better than what SVN provides.
>SVN solves the problem. It's either SVN or something worse (CVS and SourceSafe are still widely used).
That may have been true 5 years ago but it just isn't today.
>Version control is a tool. You have a set of requirements and you choose the tool based on those requirements. There is no such thing as "obsolete".
This is a pretty ridiculous statement. Of course there is a such thing as "obsolete". When an alternative comes along that does everything its predecessor did, better and even with extra features on top of that then it has fully obsoleted said predecessor. This happens all the time in software. SVN fully obsoleted CVS. C fully obsoleted B. On and on.