[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnversion feature

From: David Chapman <dcchapman_at_acm.org>
Date: Thu, 07 Jun 2012 10:20:22 -0700

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      dcchapman_at_acm.org
     Chapman Consulting -- San Jose, CA
     Software Development Done Right.
     www.chapman-consulting-sj.com
Received on 2012-06-07 19:21:05 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.