MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010033CMakeModulespublic2009-12-11 10:052016-06-10 14:31
ReporterGerald Hofmann 
Assigned ToMarcel Loose 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionmoved 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010033: Extend FindSubversion to report a compact version number for a working copy
DescriptionMake the compact "compact revision" (as produced by svnversion executable) string available in cmake.

 
Steps To Reproduce
Additional InformationFile attached. Works for me, but not sure if something missing.

I have added _WC_COMPACT_VERSION to the module output. The version string is produced by the svnversion executable which should be available when subversion is installed. My idea is to handle svnversion as an *optional* executable anyway, so there is no explicit SVNVER_(NOT)FOUND. If svnversion is not present, _WC_COMPACT_VERSION is not set at all, without affecting the return values of the remaining subversion information. This should make my modifications downwards compatible.
TagsFindSubversion
Relationships
Attached Files? FindSubversion.cmake (7,965) 2009-12-11 10:05
https://public.kitware.com/Bug/file/2714/FindSubversion.cmake
txt svninfo.txt (1,680) 2014-08-21 10:22
https://public.kitware.com/Bug/file/5230/svninfo.txt
Issue History
Date ModifiedUsernameFieldChange
2009-12-11 10:05Gerald HofmannNew Issue
2009-12-11 10:05Gerald HofmannFile Added: FindSubversion.cmake
2010-12-14 17:02David ColeAssigned To => Marcel Loose
2010-12-14 17:02David ColeStatusnew => assigned
2010-12-16 03:41Marcel LooseNote Added: 0024195
2010-12-16 04:29Gerald HofmannNote Added: 0024196
2010-12-16 07:49Marcel LooseNote Added: 0024199
2010-12-16 08:02Gerald HofmannNote Added: 0024200
2011-06-24 14:53Aaron C. MeadowsTag Attached: FindSubversion
2012-08-28 06:05Marcel LooseStatusassigned => backlog
2014-08-21 10:22daumFile Added: svninfo.txt
2014-08-21 10:26daumNote Added: 0036656
2014-08-21 11:02Marcel LooseNote Added: 0036657
2014-08-25 05:08daumNote Added: 0036671
2016-06-10 14:27Kitware RobotNote Added: 0041633
2016-06-10 14:27Kitware RobotStatusbacklog => resolved
2016-06-10 14:27Kitware RobotResolutionopen => moved
2016-06-10 14:31Kitware RobotStatusresolved => closed

Notes
(0024195)
Marcel Loose   
2010-12-16 03:41   
I briefly looked at your code. I have a few remarks.

I would prefer a separate macro. That way it's guaranteed not to break anything. For example, your code does not support 'svnversion WC_PATH TRAIL_URL', because the second argument to Subversion_WC_INFO is the prefix to use for the variable names returned by that macro.

Furthermore, I think that people who are only interested in the WC version info wouldn't want to use the full-blown Subversion_WC_INFO, because it gives way to much information. OTOH, people who want the complete WC information do not get any extra from 'svnversion'.

What about a new macro Subversion_WC_BRIEF_INFO or Subversion_WC_VERSION?
(0024196)
Gerald Hofmann   
2010-12-16 04:29   
Regarding your first remark, yes, I agree, my code does not support the optional trail url. In this case I think this is dispensable. Can't figure out a scenario where such complex call could be useful for a macro that simply returns info of a particular wc and is not used to actually maintain the wc.

_WC_COMPACT_VERSION does give additional information over "svn imfo". Most important (for me) is the trailing "M" if the wc was modified, or a mixed revision string. ASFAIK, I can't get this from "svn info". My intention is to use this information to e.g. set a prepro define and brand an executable to be built from not yet commited sources.

Subversion_WC_INFO was not added by me, it's already available in 2.8. Can't see any reason to relocate it to a separate macro.
(0024199)
Marcel Loose   
2010-12-16 07:49   
I didn't mean to say that Subversion_WC_INFO should be relocated. It was already in FindSubversion before I took over maintenance of this module.

I meant to say that I think that your piece of code should not become part of Subversion_WC_INFO, but should become part of a new macro, e.g., Subversion_WC_BRIEF_INFO or Subversion_WC_VERSION.

You do have a point w.r.t. information about changed sources in your working copy. You'd need 'svn status' for that, because 'svn info' doesn't give you that information. IMHO yet another reason for adding a new macro which only calls 'svnversion' and nothing more.
(0024200)
Gerald Hofmann   
2010-12-16 08:02   
Yep, just a little misunderstanding regarding Subversion_WC_INFO.

No objection to your proposal of a new macro. I agree, separating this will keep the subversion module easier to maintain. Thank you!
(0036656)
daum   
2014-08-21 10:26   
I do not know if you are aware of this, but actually "svn info <wc>" does NOT give you an overall revision for the whole working directory as "svnversion" does, but only for the directory node. Please refer to the svninfo.txt I have uploaded for an example.
Subversion_WC_REVISION is therefore very misleading as it does NOT necessarily give the revision of the working copy.
(0036657)
Marcel Loose   
2014-08-21 11:02   
Yes, I am aware of that. This basically is a Subversion issue. Subversion_WC_REVISION simply contains the revision number that "svn info" returns as "Revision:". I agree that this can be misleading, but you should complain to the Subversion developers.
(0036671)
daum   
2014-08-25 05:08   
I once did that for a similar/related svn behavior. The answer pretty much boils down to "intended behavior". Which is also the reason why the svnversion tool exists in the first place. I only wanted to add to the current discussion that, if you intend to tag your generated package/library/whatever with an svn revision through CMake (which we do), the output of "svn info" can be "hazardous" and
svnversion is by far the better way to go.
(0041633)
Kitware Robot   
2016-06-10 14:27   
Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.