> >> There are much better and more reliable tools for determining which
> >> revision of a particular binary you have than source keywords. They
> >> include (either on their own or in combination) but are not limited to:
> >> pkgchk, pkg(5) [IPS], digest, md5sum, bart, showrev, elfsign, the online
> >> fingerprint database.
> >
> > Those won't show which module is actually loaded into kernel, will they
> > ? (I don't know bart and online fingerprint database). I.e. you have
> > crash dump, how can you find out which module version was loaded ?
>
> Use the ::showrev dcmd in mdb
Nice, I didn't know that.
> > hg log -l 1 --template '{node|short}\n' file
>
> I believe that's one of the proposals. The NWS Consolidation
> (at least, they used to) uses a similar concept, by setting a
> variable in the top-level makefile and embedding that in each
> module's version info.
Ah. I have been asked several times by different people, and I haven't
seen this answer anywhere.
> One other thing though- I don't think we're really concerned
> about _age_ of the code so much as identifying which particular
> revision it is - as long as you've got a tip id, you can find
> the matching version of the code:
>
> hg cat -r $TIP /path/to/file
Yes, I agree. I just noted that if you look at 1.27 and 1.32, it's
obvious which is older. While looking at node it's it is not, and you
have to have workspace ready (maybe it's possible to find via web
interface, I don't know).
Thank you
--
Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/scm-migration-dev/attachments/20080703/aeb866b0/attachment.bin>
