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

Svnversion use: Was: FW: [CMake] Version embedding - how to cause a command when make is run?

From: Atwood, Robert C <r.atwood_at_imperial.ac.uk>
Date: 2007-10-05 15:39:59 CEST

 During a discussion on the cmake list, abut getting the svnversion
output automatically embedded, another subscriber suggested svnversion
would produce non-unique identifier of the source tree...

** quote
>> I said:
> > Yes, [svnversion] is the whole point! It is much easier
> >than using individual
> > revision nubmers for each file.

Alan said :
> 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

I said:

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 .
*** (end quote)

So, Here I am asking the question, can you actally get a different
source that has the same svnversion output? ( Not including using a
different repository entirely )

As I understand, and observe, if file 1 is rev800, file 2 is rev 900,
file 3 is rev 1000, and you alter file 2 and check in, it does not have
rev 901, rather it has rev1001 because the number goes with the whole
project, not the file. So the svnversion changes to 800:1001 ? It does
not remain 800:1000? If you ask for rev901 of file2 is you just get
rev900.

Thanks
Robert

 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 5 15:41:11 2007

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.