OK, got it now... Biggest problem is that SVN tags are read-only by design, so its a chicken-and-egg problem really. There may be some means of making tags writeable (temporarily!) to only one user (the service account), but if there is its beyond my SVN knowledge.
Four options if that is not possible (excuse the stream of consciousness, its been a long day): 1. Two builds, first one checks SVN for changes on all files EXCEPT AssemblyInfo. If it detects changes, it sets the version in the file to N+1 then checks the AssemblyInfo files in and tags, then copies the whole source to a temp directory (as a single zipfile would make it easier to handle concurrency problems) then exits. This will screw up if someone else checks in between the build process triggering and checking in the updated AssemblyInfos, you could mitigate that by reducing the modify time check and not updating the whole buildserver working copy, but its still a risk. Second process watches the directory, moves the zipfile to a different working dir, unzips and builds. You can probably even retrieve the build bersion from the AssemblyInfo file (or zipfile name, or text file somewhere) to keep the numbers consistent between builds. 2. Variation on #1... First process watches all but assemblyinfo, if midified then it updates AssemblyInfo and checks in. Second process watches repository for ONLY assemblyInfo changes, if it finds any it checks out the whole source and does the build, and then tags based on the number in one of the assemblyinfo files (not the modification number). If noone checks in a new change fast enough, your actual tag should match the code (even if the trunk change number is now off by one). Will require some creative NAnt scripting, and I'd keep the "modification ckeck" interval very small on the second process to minimise concurrency problems. 3. Third option - if you don't use branches at all (or much), use a branch instead of a tag: you could have your SVN admin make all branches read-only to all users except whatever service account uses your build process. Build process retrieves from trunk (or a "named" branch as appropriate), updates AssemblyInfo, builds, and runs a SVN command to create a numbered branch (instead of a tag) as the final step in a successful build. Caveat: any time your devs want to make a "named" branch they would have to get your SVN admin to create it and explicitly grant write access. As long as your SVN admin is willing to manage granular control of permissions this could work. 4. Variation on #3... set up a script that branches and then revokes write permission on the newly-created branch (IE. save your SVN admin the effort by automating it)... and have a convention that developers create their own branches that do not match the 'tag' format. Hope there are some useful ideas in there somewhere for you! It's an interesting problem and I'm sure others have come across it before, so any other suggestions from other readers would be most welcome too :-) Cheers, - Sam. On Tue, Mar 17, 2009 at 10:11 AM, Bigley, John <[email protected]> wrote: > 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]> 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 > > >
