subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Chapman <>
Subject Re: svnversion feature
Date Thu, 07 Jun 2012 17:20:22 GMT
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
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.

View raw message