John Calcote wrote:
> I have a project on which I'm trying setup some build automation. I
> think I've discovered a good way to revision these builds - I just use
> the highest SVN revision number as the component or package revision
> (eg, xyz-1.0-3454.tar.gz, where 3454 is the component high revision
> number).
>
> Two questions:
>
> 1. Has anyone ever done anything like this before?
Yes, I do that in many projects.
> 2. Is there a good way to GET the high SVN revision number for a
> sub-directory of a project?
Use svnversion (the program, which I believe it's going to become "svn
version" in 1.4). It's very very useful because it detects also local
modifications and partially-updated working copies. For instance, if the
revision number of your working copy is 345 but you have local
modifications, svnversion will print "345M". If you updated in a
subdirectories and forgot to run a top-level update (so part of your working
copy has a different revision than the rest), it will print a revision range
like "326-345". My normal build system aborts and screams if the output of
svnversion is anything but a bare number, so that it cannot be run with
local modifications or partially-updated working copies. You don't want to
know how many times I would have shipped a wrong version without this sanity
check :)
svnversion has another option, "-c", which is supposed to report the last
committed revision, instead of the last updated revision. This would be
useful because commits in other parts of the repository still bump the
global version number, even if they don't affect your project. It's not a
problem per-se: it might happen that you end up somehow with packaged builds
with a different build number, but which are in fact the same version. In my
experience, this has never been a problem.
Nonetheless, I have tried to solve this problem with "-c", but I found out
that "svnversion -c" is too picky though and always displays a revision
range (because each and every subdirectory has its own "last committed
revision" which is the last revision in which a change was made to that
directory). Thus, it's impossible to detect the partially updated working
copies if you use "-c", which is really a killer feature to me. I had
envisioned a solution: one should run "svnversion" once to check for
cleaness and after that, only if everything is ok, run "svnversion -c" and
get the highest number of the revision range it spits out. This should solve
the non-problem, if you need to.
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 1 22:34:59 2006