In the past, using mercurial with Visual Studio, I used to add mercurial changeset ids to my application so that when the user did a Help About, it would list all components and their exact mercurial revision. It would also log all changeset ids to the application log file every time it started up. This procedure even allowed me to see whether a particular working copy had been modified since the last commit (mercurial’s hg id indicates a dirty working copy by adding a + to the end of the changeset id it reports).
This was incredibly useful, since it meant that any time a user reported a problem, I could quickly build exactly the revision they were using. I could also tell when people had snuck in a quick hack to fix a problem and had neither committed the changes nor told me about it.
I would now like to replicate the same facility in my git hosted RCP application. Unfortunately, I’m rather new to both git and Eclipse RCP application development, so I’m a little unclear as whether the same technique would work.
In particular I have been unable to work out how to do the equivalent of hg id with git , how to get the Eclipse build system to call git to create a .gitignored file containing the id, so that it can be compiled into the application/plug-in, or how to get this information into the Help>About page.
If you have done this, or something similar, I would love some pointers as to how you did it. Alternatively, I would be happy to hear any suggestions about alternative ways to achieve the end result that I seek.
With a little google-fu, reading behind the lines and experimentation, it looks like git rev-parse HEAD or git rev-parse --short HEAD is probably the closest to an hg id, alas I can’t find a way to indicate that the working copy isn’t clean, so it looks like I will have to check the output of a git status --short and if it isn’t empty, append a + to the commit hash manually.
Now I just need to understand how to get these commands to be run from the Eclipse build system and where to inject this information so that it shows up in the About pages.
I can’t speak to the git portion of this question, but I can to some extent on the RCP portion. That said, you’ve mentioned that you’re not a fan of keyword substitution. I appreciate that, but as far as I know that’s a very common practice throughout the RCP build framework!
The About dialog can be controlled using an about.properties, about.mappings, and about.ini file. The Rich Client Platform Book talks about this.
What I would do is have your build generate the about.mappings file with your git hashtag.