Build Version vs Revision number

Question

I have an asp.net/C# 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

Lentha

seems like everyone point's to "tags". Any idea where i can get a tutorial on tags? and how to create them? I've, never even heard of tags – Lentha

Answer 1

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.

Jamison

yeah... this is what i am working towards, just not sure how to create the tags though :( – Lentha

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. – Jamison

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? – Susurration

@Brian, temperature certainly isn't a good indicator since yesterday's coffee is just as cold as last week's! – Faustina

Answer 2

How about using tags.

http://svnbook.red-bean.com/en/1.1/ch04s06.html

Dogfish

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 – Lentha

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 svnbook.red-bean.com – Dogfish

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 :) – Lentha

Answer 3

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.

Quarrel

i managed to get the revision number from svn using sharpsvn.open.collab.net (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? – Lentha

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 – Quarrel

Answer 4

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.

Issiah

Answer 5

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

Kobi

Answer 6

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

Stepson

Answer 7

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 http://msbuildtasks.tigris.org

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.

Galan

Answer 8

Another option is to use last changed revision as your build number. This means each time you build you auto-tag. It's easy with hudson/jenkins since you have an environment variable SVN_REVISION. The problem is that revision number get very large and hallway discussions about 1.0.0.20456 vs 1.0.0.20489 are a mouthful.

Opuntia