On 22/10/2011 18:29, Garrett Cooper wrote: > On Fri, 21 Oct 2011, Craig Rodrigues wrote: > >> Hi, >> >> I tried following: >> >> (1) Run svnversion in non-svn directory: >> >> return status == 0 >> prints out "exported" >> >> time: >> real 0m0.043s >> user 0m0.000s >> sys 0m0.045s >> >> (2) Run svnversion in svn directory: >> >> return status == 0 >> prints out "223847M" >> >> time: >> real 0m2.563s >> user 0m0.980s >> sys 0m1.187s >> >> >> (3) Run "svn info --non-interactive ." in non-svn directory: >> >> return status == 1 >> prints out "svn: '.' is not a working copy" >> >> time: >> >> real 0m0.056s >> user 0m0.007s >> sys 0m0.046s >> >> >> (4) Run "svn info --non-interactive ." in svn directory: >> >> return status == 0 >> prints out "a bunch of info about from svn" >> >> time: >> >> real 0m0.023s >> user 0m0.000s >> sys 0m0.024s >> >> >> >> I thought that since svnversion seems to always have a return status >> of 0, and >> is almost 2 seconds slower than "svn info" when run inside a svn >> directory, >> that using "svn info" is a preferable way inside a script of determining >> if a directory is part of a svn repo or not. > > $(svn info | awk '/^Revision:/ {print $2}') > > is what I use in my installkernel wrapper script. Granted, I didn't know > about svnversion some time later, but it appears that svnversion broke > some things by consolidating the .svn directories as Chris shows above > with the 'exported' line. svnversion actually does more than "svn info", which is why it's slower: 1. It descends into the subdirectories recursively. 2. It "recognizes" different checked out revisions in those subdirectories, plus local modifications and other stuff. So, while "svn info ." will only produce the version of the directory it's run from, and that regardless of any possible local modifications, svnversion will produce version number that is... <quote> ... a single number if the working copy is single revision, unmodified, not switched and with an URL that matches the TRAIL_URL argument. If the working copy is unusual the version number will be more complex: 4123:4168 mixed revision working copy 4168M modified working copy 4123S switched working copy 4123:4168MS mixed revision, modified, switched working copy </quote> I guess that for most folks that's generally irrelevant, but even I, not in any way being a developer, find it helpful to be reminded when I'm working on a system that I've fiddled with, even in a minor way. Concerning the breakage, the problem is actually not in svnversion per se, but rather in the algorithm in newvers.sh, which checks whether ${SRCDIR}/sys is under Subversion control. It would be all the same if "svn info ." was used instead, to the best of my understanding. Speaking of that, and in the context of the recursion that svnversion does, something else comes to my mind... svnversion is currently executed in ${SRCDIR}/sys, so the revision number is relevant only to the kernel sources. But FreeBSD is not just a kernel, unlike Linux, so wouldn't it make more sense to actually check the revision directly at ${SRCDIR}, thus catching possible different revisions in other parts of the base system source tree? I mean, when somebody says "I'm running FreeBSD 9.0-RC1 r226607", their kernel tree might be at r226607 all right, but they also can easily have some very different revisions checked out for lib, include, etc. Not that I really expect many inexperienced users showing with versions like "FreeBSD 9.0-RC1 r226353:226607M", but, well, you never know. As I'm pretty far away from the development process, that might not really make much sense or even sound straight nonsense, of course. :) Cheers, Luchesar P.S. As for the original problem, from my really modest experience, I find the proposal by John and Doug sound -- to run svnversion if it simply exists, and not bother looking for .svn directory/ies, which might indeed be in some unexpected places. svnversion seems to exit pretty fast when the directory is not under Subversion control, so this shouldn't cause unnecessary delays for those not using Subversion for their source trees (and if they don't have it installed at all, that's going to be even less of a problem, of course).Received on Sat Oct 22 2011 - 14:56:05 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:19 UTC