• Advertisement
Sign in to follow this  

Source Control & Automated Build/Test System

This topic is 2350 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

well I continued working on my game and feel the need to upgrade my current source-control system, as well as to add automated builds and tests. I'm currently using SVN (the repository is stored on my NAS) for source control and there is neitherautomated building nor -testing.

I feel the need to switch to another source control system since either SVN itself or my clients (TortoiseSVN, AnkhSVN) seem a bit glitchy. Every now and then, my checkout becomes unusable (forcing me to delete it and to create a new one) and then there is the lousy rename / move support of AnkhSVN (it seems to me that files are just removed and re-added, which defeats the purpose of moving). What other options do I have (besides ClearCase and SourceSafe) and which ones do you use?

Somewhere in a galaxy far, far away (and a long time from now), I might be able to actually release my game. I don't want to manually apply labels, hit the build button and the start my favourite installer (NSIS, etc..). What are my options here? Which ones do you use?

But most importantly, I would like to run a series of tests again my code before a commit (preferably automated), so I can't screw up trunk or some branch. Again, what are my options? Do you even use automated tests?

I would really like to hear about your setups & recommendations :)

Share this post


Link to post
Share on other sites
Advertisement
I actually use SVN and never encountered corruption like you talk about. Check your disks for errors. Moving/renaming files is a pain though. If I have to start again, I'll try GiT, it seems to be the standard this day and lot of people love it.

As for automatic building/labeling you could try CruiseControl.Net, work amazingly well.
For unit testing, well it's your choice, depend on the language. Using NUnit for .net application is easy to setup, and can be set to run automatically for each commits by the build machine using cruisecontrol.

Share this post


Link to post
Share on other sites
Subversion is top of the heap for centralized version control systems (those like SVN, CVS, SourceSafe, etc), generally, the centralized ones deal less-well with moving files, branch/merge, etc.

I've grown to prefer the distributed version control systems (like Git, Mercurial, Bazaar, Fossil, etc) -- Git is incredibly popular in the open source world, notably being created by Linus Torvalds and used to support the Linux Kernel development for some time. Git works great on unixy systems (Linux, BSD, OSX) and even works well on Windows -- however, there are some issues when working between unixy and windows machines. Mostly this is because Git is designed around Posix, and windows is not really Posix compliant. The unfortunate thing is that no one seems interested in fixing the issue vis-a-vis Windows -- that is to say that they are not interested in finding a way that works equally-well between unix and windows if it changes things for the unix version. Its usable on Windows but the attitude of the project will always leave Windows users as second-class citizens.

Mercurial is actually very similar to Git in function, if not design, and works more seamlessly between unix and windows machines. It tends not to allow users to dig down into the plumbing in the way that Git does (Git is basically a relational file system underneath, with a layer on top that lets it act as a version control system) which is both good and bad, but mostly good. Mercurial limits users to higher-level commands for the most part (it has parity with git's SCM commands) so for the most part prevents you from doing something stupid, on the other hand, some of Git's lower-level commands allow you to pretty up the history. Overall, I'd recommend Mercurial over Git unless you're some kind of unix power user.

Fossil is another interesting choice, which is notable because it is packaged as a single executable file (so you can put it on a thumb-drive, say), that it has an inbuilt bug-tracking and 'wiki' inside each project, and that it has an inbuilt server process so you can interact with the wiki and bug tracker locally, through your browser of choice, even when you're not connected to the internet. I haven't tried it yet, but I might give it a go soon. It works equally well on Unix and windows systems. Notably, its written in Haskell, and its used by the SQLlite project.

Also, very generally, distributed version control is very flexible in its workflow, and the common flows promote clean, stable trunks because you are encouraged to (and should) create a branch for even small work items since branch/merge are nearly free operations. In centralized systems, branch/merge was typically expensive and troublesome, so workflows usually revolved around a trunk with perhaps a few major branches, and with developers sometimes working in their own private branch and then cherry-picking code to merge upstream. This is one of the primary reasons distributed version control is touted to be better and generally have less overhead. The downside is that the concept seems difficult to communicate to people, because you no longer have the library analogy (check-in/check-out, etc) that centralized systems rely upon.

For build systems, I don't have much to recommend -- however this choice is mostly orthogonal to your choice in version control system. When doing a build, it simply checks out the latest version from trunk or wherever that meets certain criteria (perhaps you only want it to build snapshots/head/branches tagged as stable or something). I don't know that I'd bother setting up a build system for a small number of developers, at least not a nightly build type situation.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement