Using pre-build action to display svn version number

[MarkGreally]

So I have it kinda working. I just used the default VI created for post build actions and ignore the input/output panes that I dont use (this is very annoying why they cannot be edited- but we'll live). It works fine in that it writes the SVN number to the config file at build time which can be read by the application each time. However when I do an SVN commit the SVN revision number is incremented so SVN is always 1 greater that what my application shows. Obviously there is a simple work around and just add 1 to it but this is not the best way. 

[James.M]

I don't think there is a way around this. Building the executable creates new files. In order to version them, you need to commit them after they've been made. The only way to alter the file to match the SVN perfectly always would be for the SVN commit to somehow set the version in the file as its doing the commit...

[MarkGreally]

And that is where the challange lies.

[Bob_Schor · Accepted solution]

... and the Fix for this is surprisingly simple!  If you have read any of the Subversion or Tortoise books, you'll see that they recommend that you only put "Source code", not "binaries", under Version Control.  Of course, LabVIEW "source" is in "binary" format, but I interpret this to mean "Don't put Builds under Version Control".

Here's how I handle this (and I've been doing this since I started using Tortoise SVN, maybe 5-7 years ago).

1. I structure my Project folder to contain mainly Source material.  I will have sub-folders called Documentation (obvious, usually Text, sometimes PDF, but largely static), Resources (Icons for .exes go here), Host, Target (if I'm doing Real-Time).  Host and Target are further broken down with folders for Sub-VIs, Types, Tests.
2. The Project itself is in the top level of the Project Folder, and has Virtual Folders that "match" the physical folders.
3. Builds are not done in the Project space.  A typical location for the executable is \Public Documents\<Project Name> Builds.
4. I use an SVN Property file (.svnprops) that has the following settings:  svn:ignore -- *.aliases, *.dll,*.exe,*.llb,*.lvlps, *\builds,[Tt]humbs.db.  It also has the tsvn:logminsize set to 40.  You can create such a Property file by using Windows File Explorer to find the top level folder of your Working Copy, right-click and choose Properties, click on the Subversion tab (at the top), choose Properties again, click New, select svn:ignore, add your entries one at a time, and be sure to Apply Properties Recursively.  Do the same for tsvn:logminsize.  Once you've done both, you can export it as a .svnprops so you can subsequently Import it when you create another Subversion repository (and Working Copy) for a new LabVIEW Project.
5. Incidentally, I use a LogMinSize of 40 to "force" myself to create meaningful log entries for Subversion -- extremely helpful!

A peculiarity I've noticed with TortoiseSVN is that these properties often need to be applied twice (recursively) for some of the "ignore" things to stick.  In particular, if you put a new Folder in your Working Copy, you'll need to repeat the recursive Property application.

You might end up with things in your Repository that you (now) want excluded.  Use the TSVN "Unversion and Add to Ignore List" command to unversion them.  [This gets the .exe's out, for example].  If you have a non-changing .dll or something you really do want to keep in your repository, you can always simply TSVN-Add it by hand.

So now, all you need to do is open your Project, do some modifications, close the Project (that's the step I usually forget to do), Commit, re-open, and Build.  Your Build will get the latest Revision Number, and closing the Project won't result in any Subversion changes (because (a) the Builds are "somewhere else", and (b) we set Subversion up to ignore the results of the Build).

Bob Schor

[MarkGreally]

That is indeed quiet simple. My folder structure was fine to begin with. I do the build after the commit. I dont think the application and installer need to be added to the ignore list as I dont think builds are seen as changes to SVN. I added them anyway just in case. All is up to date now.

Thanks.

Mark.