Versioning for a single developer project

[earlz]

There are people who distrust opensource/free-software because they think it must be worser than a commercial counterpart. In a way, this is true since open source software is usually written by volunteers, and have a hard time recruiting user-interface designers, artists, professional testers, which while might not be important to the core functionality, it certainly makes the product appear less professional, intuitive, and/or productive.

I see that about Wikipedia all the time. Seriously, how many times have you seen a popular article remain inaccurate for more than a few minutes?

[nedbrek]

I've used many other IDEs (proprietary, opensource, and freeware) yet MSVS is my IDE of choice. I applaud the Visual Studio team for a wonderful piece of software.

This is actually a good argument for free/open source software.

The best software is that which is written by people who are "scratching an itch".

MS programmers have to use Visual Studio. They have the source, and they can fix it. When the Office people have issues, they can yell down the hall at the Studio guys. When the OS programmers are angry, they have someone to gripe at.

vi is a great editor for programmers because a programmer wanted a great editor. Emacs is a great operating system, because a programmer wanted an editor and got distracted by OSDev

[celtic]

I understand SVN. I know that none of the additional features of git make any difference to me, and I know that - to use git confidently - I would have to spend quite some time reading. And none of the projects I work on, most importantly including office work, actually use git - so that reading / learning would earn me nothing. On the other hand, being competent in SVN made me the #1 contact for SVN-related problems in our department... it's a ROI thing.

I might add to that, that I never saw any VCS except for subversion (or none ) in all professional environments that I have seen so far.

I'll add to this point: the development team uses git exclusively for applications development at work - we moved from SVN just under a year ago now, and the ROI has been immeasurable. The immediate effect was a huge shock as people moved, but now we're doing the craziest merges and little 'off-shoot' branches on ideas that previously, under a single linear history, simply weren't possible. The cost of branching in subversion is huge - and I'm not talking about the data or computational cost, because who really cares about those with today's CPU and memory prices? - but in terms of administrative cost.

All branches in SVN are a part of the same namespace, everyone else *has* to see your branch with the rest of them unless you do /branches/<USER>/mybranch or things like that - which still is pretty ugly - it just sucks. With git, I can start off work in a branch with an idea, revert it if I dislike it - and no one else has to see the mess. Otherwise I can clean it up a bit, send it up so other people can grab my branch, and maybe merge it into master (trunk) or stable later if it really works.

Many of us also use git-svn to locally develop with git and then send the changes to the actual real SVN server for the non-application repository (website, graphics, the stuff which the non-devs need) - even my manager does! (when you thought they were the last people to be adopting the comparatively harder-to-understand technology ...)

It just takes adjustment, but like many learning curves, it comes with a payoff that's simply hard to comprehend before you're there yourself.

In terms of hobby OS development, git/bzr/inherently decentralised systems come with another advantage: no having to set up a server and configuration hell associated with maybe-Apache or whatever it depends on. Just git init (bzr init), commit your initial stuff and start versioning!

My 2¢

[Love4Boobies]

With git, I can start off work in a branch with an idea, revert it if I dislike it - and no one else has to see the mess. Otherwise I can clean it up a bit, send it up so other people can grab my branch, and maybe merge it into master (trunk) or stable later if it really works.

People can go miles to hide the code until they consider it clever - it's an ego thing. Is it really useful? No. Two things will happen:

• No one else will be able to review your super-secret branch.
• If that branch is actually important to the project, you're encouraging a low bus factor for that code.

I encourage everyone to see this interesting talk. It's what 2 people that work on Google Code have to say about this problem.