

Version control for solo Mac developers - pietrofmaggi
http://cocoawithlove.com/2010/12/version-control-for-solo-mac-developers.html

======
nuxi
Too much hassle for simple projects IMHO. Fossil for version control (and bug
tracking, wiki etc.) combined with dropbox does the trick for me.

~~~
scrrr
It doesn't get much easier than git once you have set it up and learned a few
basic commands. Free, cross-plattform, fast and sexy.

~~~
nuxi
It does get easier, it's called fossil. =)

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).

~~~
blub
Does it also have a UI like TortoiseHg?

~~~
nuxi
It's got a simplified web UI, see <http://www.fossil-
scm.org/fossil/finfo?name=src/checkout.c> for an example. The diff has a
diff(1)-like output, but you can configure a graphical diff of your choice and
use it with the 'fossil gdiff' command.

------
loewenskind
>I prefer to use GitX instead of git on the command-line where possible.

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.

~~~
aaronblohowiak
Which fork?

~~~
loewenskind
Which GitX fork or which Git fork? I didn't realize either of them had forked.

~~~
aaronblohowiak
Gitx has a panoply of forks on github, some add LOTS of features.

------
warren_s
Not trolling, but seriously, is there really a significant number of
developers out there who aren't using _any_ form of version control?

~~~
thibaut_barrere
Seriously, yes, a lot... I setup SVN two months ago at a client, at my
request.

Once you're used to something so fundamental, it's hard to imagine people
won't use it as well :)

~~~
loewenskind
If it was two months ago, why did you start them out with obsolete technology?
The only reason I can think of to have SVN today is legacy situations which
you obviously weren't in.

~~~
CrLf
SVN is far from obsolete. Just because there are better alternatives now for
distributed version control, doesn't mean that the centralized approach has
suddenly stopped working.

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.

~~~
loewenskind
>Just because there are better alternatives now for distributed version
control, doesn't mean that the centralized approach has suddenly stopped
working.

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.

~~~
CrLf
You forgot the piece that SVN integrates with IDEs. This is it, case closed.

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".

~~~
loewenskind
>You forgot the piece that SVN integrates with IDEs. This is it, case closed.

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.

