How to use Subversion for non-compiled language?

Question

I want to use Subversion with a script based development system, and was wondering what to do differently to my usual situation (C#/.NET).

The normal day-to-day update/commit cycle will work fine, as will change tracking and comparison of revisions. Where I'd like some advice is around handling of deployment.

With this script system, there's no distinct build step involved - instead, deployment involves uploading a selected script directly into the host application.

Changes to a script aren't necessarily included in the next release - they may be destined for the release after that, or the one after that.

In an ideal world, I'd like to be able to allocate a script into a given release, say the "September 2009" release, once it's been tested, and then pull out all the scripts for that release with a single command.

Update

As far as I can tell, neither Tags nor ChangeLists are going to be the answer.

ChangeLists aren't persistent (don't exist in the repository) and I need a solution that will allow review much later on.

Tags are effectively the same as branches - they contain all files by default, and you just get to choose which revisions.

I'm hoping for an approach that would start off with an empty branch into which specific file revisions could be placed as required.

Update 2

Two examples, showing how I can meet this situation with featues in other tools. Note that I'm not trying to promote these tools at all, as I want to use subversion, I'm just trying to work out how.

With QVCS, I can achieve my desired result by applying a label to a specific revision of a file. That label would stay in place, attached to that revision of that file. At any time, I could do a clean checkout, into an empty directory, and specify that only files with the specified label should be copied down.

Similarly, with StarTeam, I can apply a label to a file revision and check out only files with that label.

Answer 1

"In an ideal world, I'd like to be able to allocate a script into a given release, say the "September 2009" release, once it's been tested, and then pull out all the scripts for that release with a single command."

This is exactly what tags are designed for.

Answer 2

You can manage your "future" releases with Subversion branches. When you make a change that is destined for a future release, commit it to the appropriate branch. When the time comes to pull all those future features into the trunk, merge the branch.

This isn't really all that different from the workflow for using Subversion with a compiled language, or indeed for any other purpose.

See the Common Branching Patterns section of the Subversion book for more information. In particular, the "Feature Branches" section sounds most appropriate to your situation.

Answer 3

One solution would be to start of a new branch using svn mkdir (instead of svn copy), and then selectively copying the files needed from your main branch by way of svn copy

Answer 4

I see the problem - which has nothing to do with SVN. You want to store some files in a release branch, but not others. So either branch the entire release directory and then delete the files you do not want to show in there; or create a new empty directory and copy just the files you do want.

Its is that simple. You don't need changelists or tags or anything complicated at all, and no subversion system will be able to guess which files you do want. Personally, I'd do the branch+delete option as then you can undo the deletion at a later date if you decide you do want the files back.

Answer 5

I believe that with svn 1.6 you can have externals pointing to individual files. So, if you want, you can create an empty tree structure and define a set of externals on it which bring in the files you want into the structure. This would give you a kind of 'live view' of a branch.

You could perhaps reference the file versions directly from the trunk - or you could layer your approach and use a release branch to merge in particular revisions, and then reference that release branch in the externals of your 'live view'. That way, you release features by merging revisions - keeping normal revision control and merge history, and then an svn-update on the server would pull those files into the live structure.

The downside would be that it would be difficult to switch to a diffrerent branch (say an old tag, because of a problem in the new release) - you'd have to manually edit all your externals definitions. This may not be a problem if they're all on the same directory, but could be a pain if you have to hunt around for them.

A little information on file externals are available in the svn 1.6 release notes

Answer 6

It sounds like you are looking for metadata about specific scripts. Thus one option is to store your scripts as separate files, and use svn properties. Svn properties allow you to store key-value pairs associated with a file.

For example, to mirror your "label" example, you could create a property for each file you decide to include in a particular release. In this case, create a "September 2009" property with value "true".

You can then select only the files with the "September 2009" property when generating your deployment package.

Using tags and branches are useful when you want to track the changes to your repository over time, and to generate diffs to see what those changes are -- but it is a snapshot of the entire repository...