As Alan points out, you shouldn't trust the output of "svn info" as gospel unless you also verify that "svn status" gives you *empty* output.
In the case that Alan identifies of trying to track down where a bug was introduced, a quick svn status check would show you which files were *not* up to date with respect to the svn info output... (local modifications, local additions/deletions and files unknown to svn are all reported by svn status) HTH, David On 10/5/07, Alan W. Irwin <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ CMake mailing list CMake@cmake.org http://www.cmake.org/mailman/listinfo/cmake