Until recently, I have been checking my UC build scripts into my solution folder and everything has been just peachy. However, as the number of branches increase, maintaining those scripts with bug fixes and enhancements starts requiring a lot of merges; so what I have been attempting to do is move the UC scripts into a folder outside the main source code, but still under source control. So in my SVN repository, I would have /branches, /build, /tags and /trunk at the root level. By passing the parameter path_to_solution into the UC build, I can mostly run the scripts as before, however there are a number of steps which will break in different ways.
For example, the SVN versioner checks for the SVN revision number by assuming that the build scripts are in the root of the solution folder by calling:
<exec
program="svn"
workingdir="${dirs.current}${path.separator}${path.to.toplevel}${path.separator}"
commandline="info .\ --xml"
output="_revision.xml"
failonerror="false" />
In my scenario, however, it should be:
<exec
program="svn"
workingdir="${dirs.current}${path.separator}${path.to.toplevel}${path.separator}${path_to_solution}${path.separator}"
commandline="info .\ --xml"
output="_revision.xml"
failonerror="false" />
By default, path_to_solution is "." so this sort of change shouldn't make any difference to those who follow the convention, but it would fix things nicely for me. It would probably require a fairly big audit of the source code - for instance, I found the NuGet steps don't use the path.to.toplevel, but just assume that they are running at a particular folder depth.
So do you folks think it'll be worth the effort?