On 03/ 4/10 10:22 AM, Albert Lee wrote:
On Thu, 04 Mar 2010 09:22:09 -0800, Garrett D'Amore<garr...@damore.org>
wrote:
On 03/ 4/10 05:03 AM, Dennis Clarke wrote:
Sorry for the long winding email but I am really thinking that the
header
data is nice to have around and still useful. Is there some easy way
to
get that data back ( an awesome awk/sed/grep script ) or is it lost
forever?
Lost forever. But ultimately, the data was not as useful as you think
it was. SCCS ids were only unique in the code branch that they were
part of -- S10 version 1.134 might be very different from the same file
versioned 1.134 on Solaris Nevada or Solaris 8.
Hg doesn't version files separately like SCCS under Teamware did. We
*could* build hg version numbers (for the entire repository) into ELF
binaries, or even stash them into headers via #ident, but it turns out
that this is a major bit of trouble (it forces binaries to be different
that might otherwise be identical, for example), and so we have decided
not to do it.
If you think it would be worthwhile, the ID of the last changeset that
modified the file could
be used instead. You coujld also include a date as in the SCCS-style
version info.
I think at one point this also was considered. If I recall correctly,
it *substantially* increased the time it took to build Nevada.
Again, the information here is of questionable value IMO. The #ident
flags were oft misused in the old days, and IMO were actually more
harmful than good. (For example, you installed a driver binary. But if
you didn't reboot, then you didn't get the right version, and so you
weren't actually using the version that was in the filesystem at that
time. I've seen several bugs misreported because of this.)
At the end of the day, you don't need this information. A simple build
number is probably sufficient.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
