Subversion is a free/open-source version control system. That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data, or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine”.

In early 2000, CollabNet, Inc. (http://www.collab.net) began seeking developers to write a replacement for CVS.

A free online book. This is the only resource you will need to learn all things about Subversion, including best practices when working with a team. Highly recommended. [ subversion overview ]

[ Subversion Clients & Plug-in Index ]

[Ankh Client for VS .Net]

If you want to ensure source control, bug tracking, requirements planning, project planning, continuous integration, a full development tool stack would have about twenty or twenty-five different tools. A lot of them require installing several different pieces—a database server, running database scripts, installing the code, installing Apache, Tomcat. One tool can be compatible with Tomcat 5, some won’t be. Just to get up with a basic life-cycle tool stack could take days or even weeks.

Once you’ve got the individual pieces, you have to provision projects across all those tools, and having the tools to work across those projects is additional work. When things are checked into source control, the right things should happen, such as running a continuous integration build, running unit tests, running code metrics, aggregating code metrics over time so the team can see a trend around code quality, and generate metrics that are important for their project.

And you normally don’t have a single place to go to get that information. Instead, you have to open each tool and work in that tool, then jump out and into some other tool. Even if those tools are all hosted inside Eclipse, they are discrete.

With Project Assist, a team runs through a simple admin tool, and with one click installs the entire stack, deploys the entire project, and then gives each developer on the team an XML file that configures Eclipse for work on the project. Developers don’t have to know URL endpoints, access codes, or project names. It’s all bundled up for them. They just open one file, and can immediately pull code, check in code, and are up and running.

This entry was posted on Thursday, March 20th, 2008 at 4:00 pm and is filed under CVS / RCS / SCM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.