Version Control Software

Well, I hear you on the ‘needing some entity to throw under the bus’ thing but there are plenty of projects that are much, much, much, much more complex than the linux kernel.

Your average case intake and workflow for a public entity in the social services field is incredibly complex when you consider how many interfaces, rules, and oddball requirements are involved. Add into the mix things like security (i.e. keeping the code private and secure) like you see with defense projects and things get pretty crazy.

The problem is we have 5 developers working on various projects, possibly at the same time. We need some way to manage and track all of this and prevent loss of work from overridden files, etc.

If it was just one developer (as it is now) we wouldn’t need one (which is why we don’t at this point). However, we’re looking to bring on several more developers and I want a way to keep things nice and orderly, as well as allowing me to easily check the progress of each of these projects.

With only 5 developers you should be in good shape with basic source control i.e. git-github or subversion. If you have each developer commit to around 2 hours of training then put them all into a command line interface, you’ll eliminate all sorts of fooling around with gui/clients and get right to the nitty gritty of the source control.

Simple and effective, and free.

The problem with command line is we have a few people that’ll use it that are non-developers (graphic designers, etc that need to edit images). I think I’ll probably stick with command line and I suspect our developers will as well. Probably use something simple like TortoiseGit for the others.

Thanks for the help everyone.

Having trained thousands of users on various source control systems (literally) I would urge you to reconsider that. The problem with command line is the ‘fear of the command line’ itself.

In almost all cases, the use of the command line is so simple that armed with a 1-page reference sheet most designers and non-techies can handle it. Meanwhile, the gui implementations (which mostly just put a shell over the command line) cause more trouble then you can imagine, and aren’t worth it.

I did notice the rather unclean look of most of the git GUIs. Once I play around with it, I may change my mind and just teach them command line. The actions the non-devs are likely to perform are so simple that I could probably just put together a batch file for them to run if they are having trouble.

Thanks.

You can use your SVN with an ALM platform like uberSVN http://bit.ly/ooTGgN which makes it much easier to use (and its free). I think that’s the best option.

Though this is an old thread, since it popped up again I figured I’d share my decision.

We ultimately went with Mercurial. For those not familiar, it is very similar to Git. We were initially going to go with Git, but it was being annoying to set up (we wanted to set it up so we could do anonymous pushes without the need of Gitosis or a SSH shared key, since it’s already behind our network). I got frustrated after a bit and went to look at Mercurial.

I pretty much love Mercurial. Aside from the setup issue, it’s nearly identical to Git (even all the commands are the same). It’s a distributed system. They also have a very handy TortoiseHG which is quite elegant and works very well.

Thanks for sharing your final decisions. I’ve never used Mercurial but may try it one day - I only know svn and git. I find working with git is a bit more convenient than svn, one of the few drawbacks is that it can’t version empty folders. Does Mercurial also have this limitation?

It looks like it does. I created an empty folder and went to commit, but it didn’t show up in the list. If I recall correctly, I read that it revisions individual files, not folders.

It doesn’t have the repo/repo.git mentality too. It’s all in one place (some people may not like that, but I do).

There are several hg servers, but the built in one (hg serve) with a little configuring has served as quite well. We have it on our internal network so we don’t do any authentication (since you have to authenticate to get onto the network). I’m not sure what kind of authentication is has, but it seemed to have lots of good choices.

If you’re familiar to Git, it really is almost identical (commit, branch, push, pull, rollback, etc. are all basically identical).

The two big things that let us make our final decision over git were:

  • Ease of setting up the hg server how we wanted (literally took me less than a half hour from knowing nothing to having it exactly how I wanted).
  • TortoiseHG, which is far and away better than any of the available Git graphical tools.

To me, Mercurial is essentially just a more modern version of Git.

I think you made a great choice. I have a team that is set up on mercurial and they are very happy. With the popularity of github.com, git has somehow developed a kind of an odd culture around it - social programming sounds good but I am more concerned with software delivery and mercurial does the job well!