> and neither does the SCCS keywords when they were printed out as a
> supposed version number.
>
> > (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 ?
>
> The /system/object/ objfs(7FS) helps with that. Tools like elfdump,
> ctfdump, elfcmp all work on that and can be compared with what is on disk.
Nice, I didn't know that. On a crash dump ?
> > Not that the current keywords would be always ideal solution, but it was
> > at least something ...
>
> It was a highly dangerous something though. You aren't losing
> functionality, you are losing the illusion that you ever had anything
> reliable.
I'm not arguing about that. Question which came to me was 'how will I
implement keywords'. I'm just saying that you can do the same 'stamping'
using hg, as you are doing with sccs. It's just a bit more complicated,
you have to modify Makefile. Of course it implies the same restrictions.
> > hg log -l 1 --template '{node|short}\n' file
> >
> > It prints node id of last commit which changed given file (or even
> > directory !). And it's much faster than 'hg id'. The only disadvantage I
> > can see is that you can't find which node id is older than other just by
> > looking at it.
>
> That suffers from the same problem as SCCS keywords. It only shows the
> revision for a single file and that is utterly bogus and highly
> misleading. Most modules aren't a single file.
Correct. But apart from sccs you can get the stamp for whole directory,
which might (and might not) be more meaningful.
Of course I'm not pushing anyone to do that. I'm just providing them
with the rope they want.
--
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/86c83fc1/attachment.bin>
