Sign in to follow this  
paulecoyote

Subversion - branching single file, faux pas?

Recommended Posts

Hi all, I've got several web applications which have xslts that need to be specific to the machine the application is installed on. The rest of the files in the web application directory I would prefer to always use the trunk copy. The way I'm thinking about handling this is branching just that single file - because I do not want to ever be in a position where someone makes changes to the application itself but as thoses files are in the branch rather then trunk then the trunk would not get updated. If I branched the entire directory, when merging back any web application changes I would be overwriting the machine specific xslt in the trunk with the branches copy along with everything else. TortoiseSVN seems to let me branch just a single file, but I've seen a post or two where it is discouraged. What do you think?

Share this post


Link to post
Share on other sites
Any machine-specific configuration should be in a file which is svn:ignore'd

What I normally do, is commit an example, commented with the changes which are required on a per-installation basis.

The actual config file is not in svn and is svn:ignore'd

This means that in order for the app to work, the deployer needs to copy the example file and make the relevant changes, on a per-installation basis. Of course this should be documented, after which it's fine.

Mark

Share this post


Link to post
Share on other sites
Thing is it's useful for that configuration file to be under source control, because they are all variations on a theme and I want changes in that file to be tracked. Specifically it's a few xslt files, so it's a site dependant transformation which stays the same apart from minor variations.

Perhaps as it's a release specific thing rather then anything else it should be a tag rather then branch?

Share this post


Link to post
Share on other sites
The normal way to deal with files that need to be configured specifically for the deployment or development environment is to provide a template file and put that in source control. When deploying or setting up for development, you then make a copy of that file with the real name. IE, if your web apps need a web.config, put a file called web.config.template in version control, and have the person doing the deployment make a copy of that named web.config when installing the app.

If you need to propagate changes to the template into the deployed files, things get a little hairier, but it's still possible. Using something like GNU diff3 to perform a three-way merge between the various versions of the template file and the deployed file might be one way.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this