Source code control

[Robert D. Smith]

As the subject states, is anyone using any sort of version control software on a small, at home, hobbyist kind of scale? Looking for something that is not 'create a new directory/backup file' but it also doesn't need to be bloated like microsofts vss.

Thanks.

[Tina Smith]

I have my own SVN server. (Visual SVN Server, on Windows).
My main goal in picking it was something that was free, easy to set up, configure, and that I didn't need to do any research to use. So I picked SVN, since I'm familiar with it through work.

I'm not concerned about the amount of space that it takes up - my "hobbyist" repository is only 50MB or so.

[Rob Spoor]

I'm using Assembla for a free online, private SVN repository. If you don't mind the code being coderanch, you can also create a project on SourceForge and use their versioning systems. Github is also a possibility but I haven't tried that yet.

[Martin Vashko]

I'm using Mercurial. It doesn't need any server at all, the repository resides in your project directory and the whole thing can be easily backed up just by copying it elsewhere. I assume this is true for most of the distributed systems (eg. git).

[Paul Clapham]

I'm using SVN at home as well. There's an Eclipse plugin for it, which is important for me since I'm using Eclipse. But it's very likely that the other systems mentioned in this thread also have Eclipse plugins.

[Jim Venolia]

I use RCS if everything is in a single directory (I develop in a cygwin environment), or Perforce for multiple directories. Perforce is also free for individual use, and it's what I use at work.

[Marco Ehrentreich]

I'm using Git, Mercurial and SVN (with my own server) but I prefer Git.

[Tim Cooke]

git is my choice pretty much across the board right now. We use it at work and I also use it at home for personal projects. The IntelliJ IDEA out-of-the-box support is very decent too.

[Robert D. Smith]

Thanks for all the replies. They give me someplace to start.

[Pat Farrell]

github will provide you a free repository just for signing up. Then you can use git and let github provide redundancy.

I used to run my own SVN server on a linux box in my basement. That worked well, and got me one level of redundancy. I'd use it again in a pinch.

I really like having the redundant storage out of my house. And I prefer the git approach to merging to the one in svn. This is IMHO, but I'm not the only one who things git is better than svn.

[Jesper de Jong]

I use Git both at home and at work.

At work we have worked out a branching model for working with Git. We work on features, we create a branch for each feature and when the feature is complete, tested and accepted, we merge it into the main branch. Once you get used to it, working with branches in Git is very convenient.

I have a few hobby projects at Github.

By the way, Git and Mercurial are a lot alike. Like Github for Git, there's Bitbucket for Mercurial.

[E Armitage]

git and mercurial are distributed version control systems while SVN is not. Generally, it is better to use distributed version control because you can do more things offline e.g branching or checking file history.
github and bitbucket both support git and have a free private repository but bitbucket also supports mercurial. Github seems easier to use for most people.
I've used assembla for svn, and both guthub and bitbucket for git.

Here are some comparison links
http://www.infoworld.com/d/application-development/bitbucket-vs-github-which-project-host-has-the-most-227061
http://cloudengineblog.wordpress.com/2010/12/13/why-we-chose-mercurial-and-bitbucket/
http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/

[Pat Farrell]

E Armitage wrote:git and mercurial are distributed version control systems while SVN is not. Generally, it is better to use distributed version control because you can do more things offline e.g branching or checking file history.

I'm not convinced on this "distributed is better" argument. Just IMHO, but I'm not seeing it. The industry trend is to trust the cloud, which means you are never off line.

I much prefer git over SVN because the merge process (conflict resolution) is easier with git, but that is not really because its distributed, but rather just because its a better implementation.

[E Armitage]

Pat Farrell wrote:.. which means you are never off line..

Except when you are.

[Pat Farrell]

E Armitage wrote:

Pat Farrell wrote:.. which means you are never off line..

Except when you are.

When I'm on the beach with a drink with a funny umbrella, I don't care about source code control. YMMV

[Jaikiran Pai]

Pat Farrell wrote:

I much prefer git over SVN because the merge process (conflict resolution) is easier with git, but that is not really because its distributed, but rather just because its a better implementation.

One of the main reasons why I like git (and even mercurial) is the fact that they allow me to create and manage multiple local branches as if I were switching directories. Compare this to SVN where creating/managing branches is a major task in itself. The ease of managing (and merging code between) these local branches (in git and mercurial) has allowed me to work on different features and keep switching between them as and when I wish.

[Martin Vashko]

For hobby projects, I prefer distributed systems over centralized ones simply because I don't have to set up any server. It might be a simple, minor step, but nonetheless, it is one step less. Mercurial allows me to get a new computer, install Mercurial, copy my project over there and I'm done - as far as source code control is concerned. Also, I can create - and delete - a new repository on a whim.

In our office, I've arranged a switch from CVS to Mercurial for these reasons:

* I can do local commits and not publish them until ready. For larger features, we use branches as well, but I don't want to create new branches for a one day tasks. So this way, I can commit several times a day, even though my work isn't ready to be published yet. This was one of the main reasons.

* Offline work. It doesn't happen a lot, but it sometimes it does. Furthermore, some operations (such as searches across the entire repository) are way faster when the entire repository is local. Initial cloning does take much longer than in a centralized system, but we have a stable team and this is not a concern for us.

Over the time, I've found the following additional advantages:

* Even when our office server is down, I can use email to send patches to a colleague who needs it. When the server goes back on, we just push the work into it, and that's all. Happened about twice, but it was really useful.

* The entire repository is protected by a checksum. We do hg verify daily, just for the peace of mind.

* The branch management seems much cleaner to me. A branch always contains all the files in the repo, no way around it. In CVS, I was always a bit anxious that I have forgotten to put some file (or directory) on a correct branch. In Mercurial, I have a graphical representation of the entire history, and I know that there is no file trailing behind. (Actually, this probably was a supporting argument for the switch.)

* Every commit has a unique ID. Our build script incorporates this ID into the build, so we are always able to identify the exact changeset from which it was compiled. We obviously use tags for all final releases of the project, but not for intermediate versions that are going to be tested (for example).

* There's a quite powerful query language to examine the history. Thanks to this, I'm able to answer the questions "in which version was this change published" and "which unpublished changes do we currently have" quickly. (Note: we do track these things in issue tracking systems, but we need to look at the real code when it seems that something was not correctly updated in the issue tracker.)

Perhaps some of these might be achievable in a centralized system as well, but frankly, I haven't looked back after the switch.

[Tim Holloway]

Pat Farrell wrote:

E Armitage wrote:git and mercurial are distributed version control systems while SVN is not. Generally, it is better to use distributed version control because you can do more things offline e.g branching or checking file history.

I'm not convinced on this "distributed is better" argument. Just IMHO, but I'm not seeing it. The industry trend is to trust the cloud, which means you are never off line.

I much prefer git over SVN because the merge process (conflict resolution) is easier with git, but that is not really because its distributed, but rather just because its a better implementation.

You only have to be constantly online if you are constantly posting changesets to a central repository. This, by the way, is one of the virtues of git, which allows you to post changes locally, then push them online when you are back in touch with the cloud.

I have no choice about distributed version systems since a lot of work is being done by contractors on other continents. The master repository runs on one of my servers, but we all use it in the same basic way.