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).
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
