Hey There

I have an app that uses subversion for source control.

My app automatically increases it's AssembleVersion and AssemblyFileVersion on each build which works like a charm, and displays the build number in the administration side of the site.

We keep track of AssembleVersion and AssemblyFileVersion's when we do deployment, however, when an issue arises and we need to roll back to a certain version, we have no idea which revision to target in subversion.

I have few ideas:

  1. Save AssembleVersion as comment in each file
  2. Have a keyword in commit comments that get's replaced by AssembleVersion on each commit(still need to figure out how to do it)

Any help and suggestions will be appreciated

Updated: option "1" is actually a stupid idea,cause this will mean that everytime i build, all files will be marked as updated and when i commit, every single file will be updated

+4  A: 

How about using tags.

Chris Diver
Maybe i should scratch up on subversion, cause even after reading the "simple" and "complex" examples, i still don't even know where to begin with the tags
Dusty Roberts
I think it depends on how you use subversion, are you using something like tortoise SVN or from the command line, the samples in the book are examples of using the command line tools. I recommend having a look at the rest of the book if you want to brush up
Chris Diver
yeah, i use gui tools like tortoise and ankh, i've never used command line (purely cause i had no need to), but i am doing some reading now :)
Dusty Roberts
+1  A: 

You could tag the Subversion trunk with the AssembleVersion or AssemblyFileVersion, whichever makes the most sense.

You could also keep track of the Subversion revision number the same way you currently keep track of the AssembleVersion and AssemblyFileVersion when you deploy.

Gilbert Le Blanc
+1  A: 

Apply a tag to your source tree after you have updated the AssemblyVersion and AssemblyFileVersion.

Martin Liversage
+1  A: 

When I build, I put that build number everywhere.

  • I put it in a tag in svn.
  • I put it in the Assembly metadata of every assembly I build.
  • I append it to the end of the filename in my installers.
  • I put it in the footer of each of my deployed webpages.
  • I put it in the footer of my reports.
  • I put it in the splash screen of my client side apps.
  • I put it in the welcome screen for my installers.

The only thing I don't put it in is my coffee, which I take black.

All of this lets a maintainer know at a glance exactly where the code came from for what they're seeing, whether they're viewing a webpage, or looking at the properties of one of the built assemblies in Explorer, or whatever.

Dave Markle
yeah... this is what i am working towards, just not sure how to create the tags though :(
Dusty Roberts
all you have to do it use the "svn copy" command, and that will create a tag anywhere you want. All a tag is is a "copy", which is implemented as a "pointer" in subversion. You'd perform this command inside your build file or inside of your build management system. CruiseControl, for example, makes this tag for you just by configuring your project properly.
Dave Markle
Sorry, I have to disagree about not putting it in your coffee. How else are you suppose to know that it is left over from the day before?
Brian Gideon
+1  A: 

You could "branch for release". Before creating a release build you could branch the trunk and then create a tag on the new branch with the release version number.

              + release tag
            +--------------------- release branch
----------+----------------------------------------------------- trunk

This would allow you to keep track of all individual releases in SVN. It would also allow you to make isolated bug fixes on release branches that could be released as patches. The bug fix could then be merged back into the trunk.

              +                 + patch release tag
             /                 /
            +-----------------+-+---- release branch
           /                    | merged fix into trunk...
----------+----------------------------------------------------- trunk
+2  A: 

Tags aren't really useful if you happen to build often. Maybe find a way to update Assembly version based on the svn revision instead? Also include the branch name, because they share the revisions.

And you should be able to extract the assembly version in your ASP.NET pages and print it programmatically in a footer or something.

i managed to get the revision number from svn using (SharpSVN), however this creates a bit of a pain... why?!?.... well, when exactly do you tell it to check for the version, and where do you save it?
Dusty Roberts
Tehre is a custom task called AssemblyInfoTask that updates assemblyversion at build, so you could use a task like that. However, it might need some tweaking in order to get the actual revision-number in. I haven't used this myself, because we went with the simpler solution, export a text-file with revision number that is included in the web site, just as a hint for us. Downside is that we cannot see the revision number on our dll's
+1  A: 

Tags/branches are definately the recommended approach here.

You can also (or additionally) include the svn revision number in your AssemblyInfo. One approach is to use the AssemblyInfo task from the msbuildtasks project at

For more info, google msbuild svn revision assemblyinfo

You could then do without tags/branches, as you can always check out a specific revision, and/or create a branch from a specific revision.