views:

551

answers:

4

I've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.

My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.

Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?

A: 

The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.

Joseph
That makes sense, however I'm planning on using a Date Versioning scheme, where my libraries would have their versions set to Major.Minor.Revision.Build where Revision = the date (20090624 today) and Build gets incremented with every build.
rie819
Each of the Major/Minor/Revision/Build components must be less than 65000, so this won't work.
skolima
@skolima I didn't know the versioning scheme the OP was trying to achieve. However, I still think my answer is viable for others that might come to this question, which is why I'm leaving it up for scrutiny =P It has really been a very effective configuration for me to do my publishing.
Joseph
@skolima Thanks, I wonder why people still have stuff like this posted, very misleading even if it did work for him in 2005. http://weblogs.asp.net/bradleyb/archive/2005/12/02/432150.aspx
rie819
+4  A: 

You can use a Filtered Source Control Block to exclude certain files from the trigger.

JP Alioto
Excellent, thanks JP!
rie819
+1  A: 

I just posted a bunch about my default build process here which may be of some interest to you: http://stackoverflow.com/questions/1039741/svn-website-development-and-deployment-solution/1040056#1040056

Andrew Siemer
Thanks, would you be able to post your custom ANT script (or how to do it) that generates the report on all TODO tasks? That's absolutely brilliant!
rie819
I don't know what language you are using but you can contact me offline and I can send you the code. Search for my name and you will find me! The idea is simple though. My custom task searches through the source directory in my trunk and essentially parses all the .cs files and looks line by line for anything with //TODO: in it. It compiles a list of the todo comment, the line number it was found at, and the file name and location of the file. This way it is easy to figure out what needs work.
Andrew Siemer
I also have a comment header for //CODEDEBT which has a specific format to it. Something like //CODEDEBT initials of developer, time estimate in hours to address code debt, and a comment describing the code debt. This looks something like://CODEDEBT ATS, 5, used an in-efficient loop to perform XYZ task
Andrew Siemer
+1  A: 

Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!

skolima