"Hardcoding ini-File Settings" or "Automatic Revision Number with tortoise"

Question

Hi all,
we use a SVN Repository with tortoise here at our company for version control.
I'd like to get the revision number hardcoded into the Application (.exe version).
I've allready found out, that there is some tool which can scan a directory and replaces a constant string in a file with the current revision number.
(So I could automatically generate a .ini file with "Ver=...RevNr" as content)
But I have no clue, how I can hardcode a file into the application with the labview builder.
(I think of something like the .ico file, which is hardcoded into the application too)
Has someone a sollution for this?
thanks
Mario Hirth
Solved!
Go to Solution.

Answer 1

Hi Mario,
I want to
ensure you mean what I think by "get a revision number hard coded in an Application"
When we build
an executable we
display a revision number on the front panel of our application and
we also have a Help -> About menu that displays the revision number
and other info like build
date and time.
If this is the sort of thing you want read on for some suggestions.
I have a software release VI
which contains control for things like build data, revision
number etc. This
Vi is shown from the help ->
about menu and
by an indicator on the
front panel of
our main application.
Manual revision control
Before every build
you edit this
Software Release VI
putting in the
details you want
in the controls, set these to be the default values and save the VI. When you build the new
values will then
be displayed in
your executable application.
This method is
simple to implement
and test; it is a good way to start. You just treat this VI as any other from the
point of view
of your source
control system.
However this method
has problems (people
forgetting to do
the change before
the build, people not knowing the next
number etc) and very
soon you will
want to move to an automatic revision control system.
 I use and strongly
recommend the OpenG builder
rather than the
NI builder, for
a number of reason.
1) Good API,
to help you script you builds automatically
2) Good hooks
for pre-build, post-build
and call-backs VI
integration. For example
automatically zip up
your application after
a build an email to somebody.
3) A built
in revision system
you should be
able to get up and running without much trouble
4) The Build
configuration files are
in a human readable format.
In our system
which using ClearCase
and not SVN but the same principle applies, this
is a simplified
description.
 I have three
basic files that
are used to auto revision, an ini file
that holds a record of all build for example - 001 29-Nov-2008, the software release
VI mentioned above
and I use the OpenG builder revision file to allow an easy built in hook in the OpenG builder.
When a build
starts a pre-build
trigger runs a
VI to look in the ini file to see what the next build number should
be, it then adds in a new entry with this new build number and various other information we
store, the .ini
file is then saved. In our ClearCase system I used a special config specification to
ensure that EVERYONE
sees the same
version of the
ini file (the
latest) and after
it is checked
in the latest
is immediately updated
with this new
save version again
so that EVERYBODY
can see it.
The pre-trigger VI then opens in edit mode the software release
VI in edit mode and plugs into the various control and indicator
the values read
out from the ini. The version of the software release VI is then saved and closed and then the build start. I do not worry about keeping
these edited versions
of the Software
Release VI in
the config control
system, in fact
I throw them away after the build is finished, they are in effect only templates
it is the ini file that
counts.
 Hope this helps
as a simple guide
cheers  
Dannyt
Danny Thomson CLAD
Sub10 Systems Ltd