Say I have some C++ project which builds an exe or dll file. The project is checked into a SVN repository. I want to automatically synchronize the revision from SVN with the version resource embedded in my exe/dll file, i.e. the version should be something like $major.$minor.$svn_revision.
Any ideas on how to achieve this? Are there any out-of-the-box solutions available?
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- thread_local variables initialization
- What uses more memory in c++? An 2 ints or 2 funct
相关文章
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
- What exactly do pointers store? (C++)
- Converting glm::lookat matrix to quaternion and ba
- What is the correct way to declare and use a FILE
You might want to look into Subversion Properties and Subversion Keywords. They don't solve the resource problem since they always include that damned
$KeywordName: ...$
part. Custom properties do provide a nice method for making metadata available in batch files and what not.Anyway, I looked for a solution to the resource problem a few years ago and didn't find one. So, we created our own home-grown solution. We changed our RC file to include a header file that was generated during the build process. The RC was dependent on the header and the header had a custom build rule that invoked a batch file to generate the header. The following snippet will extract the current revision from the output of
svn info
.Then we created a component specific version stamping header named
component-info.h
that looked something like:Finally, we had a product-line version file that defined the product information named
product-info.h
:Then your resource file includes
component-info.h
and uses the various defines in the appropriate places (e.g.,FILEVERSION MY_VERSION_NUMBER
). This structure gave us a lot of flexibility and traceability in the whole version stamping process. It grew from a simple chunk in a batch file into this multi-leveled monstrosity but it has worked very well for us for the last few years.I find it hard to believe that no one has found a better way to do this yet. Then again, I haven't investigated it for a number of years. I would assume that you could add a custom
.rules
file that defines a custom tool that handles this.This is great help, thanks. I've refined this for Visual Studio 2008 if it's of any help to anyone.
1/ Created a /Build folder within each project
2/ Copied AssemblyInfo.cs to the Build folder as AssemblyInfo.cs.txt, set the Build Action to "None"
3/ Edited the AssemblyInfo.cs.txt to have version attributes as below:
4/ Added the following to the Prebuild events:
This works everytime you compile.
I am using VisualSVN/TortoiseSVN and VisualSVN Server with Visual Studio 2008.
UPDATE:
My colleague has just updated his working copy and AssemblyInfo.cs is conflicted. Seems obvious. I have excluded it from SVN using VisualSVN to resolve this.
If you have TortoiseSVN installed, then there is a program installed with it,
SubWCRev
.If, in your file, you have this value:
Then it'll be replaced with the highest committed revision number if you execute something like this:
This will copy from
yourfile.txt.template
, do the substitutions, and write toyourfile.txt
.Note that there's a lot of other macros you can use as well, if you execute
SubWCRev
without any arguments, it'll list them all on the console.The answer by Program.X works great. I'd like to add, though, that if you build your executable before committing your changes, the revision will be one less than the actual revision number of the running code. To mitigate this, you can set the versions to
That will put a 1 on the end if there are any local modifications, and 0 if not. So if you look at your executable later and see 2.0.54.1, you know it's probably actually revision 55.