I am using the FilteredSourceControl block to prevent an endless loop of building, that's not the problem. The problem is that I can't create a tag with the changed version related files.
John ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Sam Calder Sent: Monday, March 16, 2009 7:38 PM To: [email protected] Subject: [ccnet-user] Re: CVS to SVN conversion problem Some people modify their AssemblyInfo files, don't check them in, and do the build - and live with the fact that the tagged AssemblyInfo files are technically not correct. Presumably if you ever need to build from the tag, you'll know to manually update your AssemblyInfos to match, or set up a separate "build from tag" script to use the tag name in the files. Or just use the binaries you built the first time, which of course you backed up somewhere safe ;-) Alternatively you can use a FilteredSourceControl block (see the documentation for that block for an example that includes AssemblyInfo files). Disadvantage here is that if you check in the modified files it'll increment the change number in SVN, so only every second change list will get built (you may not care if your versioning scheme does not include the change number though). Cheers, - Sam. On Mon, Mar 16, 2009 at 7:02 PM, johnbigley <[email protected]<mailto:[email protected]>> wrote: I am converting a Cruise Control .NET project that uses CVS to one which uses SVN and I am running into a big problem. The current project updates the AssemblyInfo.cs and other version related files with a version based on the label, commits these files, uses msbuild to build the assemblies and executables, and labels/tags the source that went into that build. This all works fine in CVS, but not SVN. The problem I am running into with SVN is that if I change these files and check them in before it runs update, it apparently knows the SVN revision of the code when it started and does an update specific to that revision. This revision does not include the version changes that were made. If I change the configuration to make the changes and do the commit after the update, then it solves that problem, but when the tag/copy is done it uses a specific revision that does not include these changes. If I change the logic to not commit these changes then the build picks up the correct version but the tag/copy does not include the version changes. If I move the commit to the very end I get the same problem; the wrong version files are in the tag. Does anyone have a good solution to this? John
