On 6/7/2012 9:27 AM, Elmar Grom wrote:
Hi,
I am in the process of putting together make files for firmware builds
and run into an issue that I didn't see addressed in any of the issues
lists. One of the things I want to do is to tag the SVN revision that
a binary was built from onto the file name (this was actually
requested by manufacturing and I agree with their view point). The
revision is easy enough to get from svnversion. The problem is,
that when I run it in my working directory, inevitably I get a mixed
revision result, even if I have just committed (something like 3:26).
While this may be informative to me as a developer, this is not
something I can embed in a file name. At the same time Make has no
ability to extract just the part after the colon.
I see three solutions to this problem:
1. create another directory and do a clean checkout of the version I
just committed. I tried this and it works well. Cumbersome though.
2. implement an external tool that runs svnversion and then
disassembles the result to get the correct number for use in a
file name. Ugly, too many tools needed already to get every day
work done.
3. implement an option in svnversion that makes it to only spit out
the highest revision number (no colon). Alternatively, the colon
could be replaced by any character the user likes. That way
something compatible with the file system can be chosen. I guess
what I meant to say is, it would be nice to have control over the
/format/ in which svnversion reports the version.
Thanks for taking the time to read and form an opinion about this.
Elmar
Rather than a clean checkout; you can run "svn update" in the root
directory of your working copy. The colon says you have a "mixed
revision" working copy, meaning that parts of it represent an earlier
state of the repository. This is not what you want. An update assures
all commits by you or other developers are incorporated in your build.
You should not trim off the lower revision number, because it is telling
you something: the binary you just built cannot be reproduced directly
later. You would somehow have to rebuild the on-disk state your working
copy. That is not the point of a revision control system!
A freshly checked out working directory has the advantage of ensuring
that there are no local changes to files that would also prevent exact
reproduction of the build. What you choose is up to you, but exact
reproduction is the goal.
--
David Chapman dcchap...@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
