Maintaining Dev and Prod Versions of Projects

[DavidWhite]

Is there a "correct" way to set up project and solution files so that they can be copied from Development to Production folders and rebuilt before distribution? I am using Subversion repositories (local to my machine), to maintain my source files, I would like to be able to also check in the VS project files, and then check them out to the Production folder, but some of the file paths remain absolute. Which files do I need to copy over - I expect to need the source files,vfproj and sln. Do I also needu2d and suo?

I have a number of projects, with some shared files, that I want to be able to clearly separate the development and production file sets.

thanks,


David

[IanH]

I have the .vfproj and .sln files under version control (in addition to the usual source and documentation files). I've not come across any issues relocating the project (clean check-out to random folder, start VS, load solution, select configuration, hit build, drink coffee, run tests, copy final exe/msi/whatever, delete random folder tree, knock off and go to pub) - the paths in my .vfproj and .sln files must all be relative.

I have *.u2d as one of the paths to ignore (in the svn:ignore property) for each project directory and similarly I ignore *.suo in the solution directory, so they had better not be required! I also ignore *.user, but that might be a hangover from VC++ project debug settings.

Where I have files that are shared between "solutions" (to use the VS terminology) I put them in a separate directory in the subversion repository and then bring them into each solution using an svn:external reference. This is a lttle clunky (they need to go into their own folder in the working copy), but it is bearable. I typically have it such that the external reference points to the tip of the relevant revision tree (you can fix it to be a particular revision if you want to), which means that if I make a change to a shared file it will get propagated via subsequent check-ins and updates to other solutions. That means that breaking changes and bugs get propagated at the same rate as feature additions and bug-fixes, not sure who's winning that race yet...

Are you familiar with the anhksvn VS add-in? While most recent release (which uses svn 1.7) has thrown the odd exception at me, I've generally found it very reliable and useful.

[DavidWhite]

thanks, Ian.

I'll look into the external reference command in SVN. I'm using the Tortoise SVN interface, and while I have AnkhSVN installed, do not tend to use it except to run Diff on the working copy. I normally do the commit from Windows Explorer.

I had noticed the emails about 1.7 exceptions, but have not seen any problems myself. I'll happy with SVN, have been using for 8+ years, and am up to over 100 commits on my biggest project. Had to go searching through the repository recently when a user hit an unusual runtime error which related to changes made several years ago. I too, have found SVN to be extremely stable.

Thanks,


David