Page 1 of 1

SVN Best Practices for Web Development

Posted: Fri Oct 05, 2007 7:56 am
by choppsta
I'm trying to get to grips with Subversion, and having read the svnbook and played around with it a little, I think I get the "rudiments". The thing i'm struggling with is finding quality information on what the best practices or application specific techniques for using Subversion are, in particular for web development.

For example, I'm working on a project which will have it's own repository, but will also have several svn:externals to bring in library files, etc. It's recommended to use a tagged version of the library files to protect it from changes that could break the project. This makes sense to me.

Now, when working on the project i'm invariably going to end up tweaking a library file or adding something to it. Here I'm a bit stumped as to what the best thing to do would be. Choices I can see are:

1) Just commit the changes. This would probably be bad because the tagged version would be changed and could affect other projects. The tag should be a final snapshot.
2) Branch the changes. I would have to then remember at some later point to merge branched changes into the library trunk of which there could end up being many and I can see it getting messy pretty quickly. I'd also have to change the svn:externals definition to reference the new branch each time.
3) Don't make any changes to externals here. I would have to make a point of working on external libraries seperately then going in and changing the externals definitions for projects that use them.
4) Set svn:externals to reference the trunk whilst in development and then change it to a tag once the project goes live.

3) is a little strict and so I'm leaning towards 4) at the moment, but it would be good to get an idea of what other people think and how they use Subversion in general for web development. Any tips would be greatly appreciated.

Posted: Fri Oct 05, 2007 9:15 am
by John Cartwright
It is generally not a good idea to modify external libraries, as you have found. A much more common way to modify existing libraries is to simply extend them and override the behavior you wanted to modify. This is of course assuming it's not spaghetti.

Posted: Fri Oct 05, 2007 9:35 am
by choppsta
Perhaps I was unclear. These libraries are code I have developed and in the course of working on a project I will usually end up refactoring something, adding a new feature or fixing a bug. I'm sure i'm not alone in this.
A much more common way to modify existing libraries is to simply extend them and override the behavior you wanted to modify.
My question is really about how people use Subversion, and I don't really want this to turn into a "inheritance vs composition" thread so I won't comment on this!

Posted: Fri Oct 05, 2007 9:52 am
by feyd
Since the external is linked to a tag, it shouldn't affect the project unless you update the reference. If you don't want to deal with needing to shift the tag, then pointing the external to the trunk is fine. Provided you are using Unit Tests (or similar) religiously and the new libraries break your code, you'll know quickly enough.

Posted: Fri Oct 05, 2007 1:37 pm
by jmut

Posted: Sat Oct 06, 2007 7:21 am
by Weirdan
When working on a project we have svn:externals pointed to trunk version of the libraries, and when the project is released we branch it and fix externals in the branch to point to tagged/branched versions of the libraries. This sometimes force us to release project and libraries simultaneously though