On 2007-10-05 14:28+0100 Atwood, Robert C wrote:


>> From: Alan W. Irwin (on cmake list)

Yes, [svnversion] is the whole point! It is much easier
than using individual
revision nubmers for each file.

Although not nearly as informative.  I just tried svnversion,
and it only
gives a range of Revision numbers for the source tree. That's
a non-unique
way of identifying source trees

How so?
As I understand the range is the range of project revision nubmers at
which the most recent changes for files has occurred.

But I am fairly new to SVN after switching from CVS, so I would like to
know how identical svnversion output from different source trees would
come about? Maybe I should ask that on the svn list as well .

If you confine yourself to committing, then that (AFAIK) always increments
the maximum number in the range so you should be okay for that use case.
However, suppose you use svn update --revision because one of your mass
commits introduced a bug and you are systematically trying old revisions of
files to see which is responsible.  (I have been there and done that!) To
take a concrete but simple example, suppose you have five files which all
have 3 possibilities (1,2,3) for the revision number. IOW, each file changed
for each revision. Then using svn update --revision you can create 3^5 = 243
different combinations of revision numbers for the various source files in
your source tree, and svnversion will identify all such different source
trees identically.  In fairness, you might not use svn update --revision
that often so svnversion will normally give you a unique identifier, but as
the concrete example shows, not always, particularly when exploring old
revisions to help track down a bug.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________
_______________________________________________
CMake mailing list
CMake@cmake.org
http://www.cmake.org/mailman/listinfo/cmake

Reply via email to