Source control/management of implementation of an existing open source project.

Question

I'm currently installing and configuring an open source project on a test server. I've been well trained to use source control, and I want to make sure everything I do is managed properly (both for me, the sole dev/admin, and for future maintaners). The open source project is available as a source download or by svn checkout.

I want to have my own source controlled version of the project. I don't intend to be changing the (java servlet) code much (if at all), but there are configurations, XML files, XSL, CSS, etc. all involved that I definitely want to be source controlled.

Should I go ahead and just make my own local repository of all of the source code? Should I try to only control the files that I need to change? In that case I would want the directory structure to match, so I could do checkouts directly to the build directories.

Answer 1

I would check in all code, because even though you don't want to change them or don't see a reason to right now, someone else might see a reason later on. Also, there might be a bug, or simple refactoring to improve maintainability or performance, etc..

A basic layout for SVN would be:

branches/
tags/
trunk/

And the general directory layout (underneath those three) should of course match your application so you can check it out and run it right away. You could however do slight modifications through a build file, etc.. But I guess checkout and go is always nice. For more information, or pointers on best-practices I would look at other opensource projects using your technology.

As for configuration files - I wouldn't check those in. Most projects however check in a foo-dist file which shows the user all configuration options. At the minimum, they would need to copy foo-dist to foo to enable the default configuration.

Also, have you looked at Google Code, Sourceforge or github for project hosting including version control? All three offer you a ton, for free - also free in terms that you don't need to take care of a server for your project hosting, etc..

Answer 2

Having two checkouts to the same directory tree won't work. If you check out your source, and try to check out the OSS project source, any directory they have in common will fail, saying it's already a working directory for a different project.

If you can gather the css, xml, xsl etc. into a common directory, you can put those in a single directory in your own project's svn, and then check them out into a directory in the working directory of the OSS project.

~/Working => svn://samhoice/project/trunk

~/Working/osscomponent => svn://osshost/project/latesttag

~/working/osscomponent/config => svn://samhoice/project/trunk/config

In this structure, the osscomponent directory does not exist in samhoice's svn repository. It is added by your setup script as the working directory root of the OSS project. The config directory is not checked out from the OSS project, and doesn't exist there. The config directory is created by your setup script and the config directory is checked out there from your project repository.

So in this directory structure you have three checkouts. There is no recursive overlap, so you have no conflicts between svn mappings on any subdirectories.

If you need your config files to be arranged within the structure of the OSS project, add some symlinks with your makefile or config script. You can also probably do this in a post-checkout hook in your svn client.

I use a structure like this for one of my projects, for sharing some code between two project trees. The shared stuff is in a subtree like I recommended for your config section.