On Tue, 25 Apr 2000, Jim Bloom wrote:
> The RCS info stored in the binaries is insufficient for this purpose. There is
> no record of the versions of all included files. Changes to constants and/or
> macros would not be identifiable.
Yes, you're right, I'm afraid. This could theoretically be s
The RCS info stored in the binaries is insufficient for this purpose. There is
no record of the versions of all included files. Changes to constants and/or
macros would not be identifiable.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
>
> On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
>
On Tue, 25 Apr 2000, Kris Kennaway wrote:
>You've never run ident(1), right? :)
Very cool! No I hadn't. I was working with the assumption that it was
probably possible, but I know very little about how RCS actually works.
I just know that it does work and that's always been enough for me to
us
On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
> The only way something like this is feasible is if the binaries
> themselves contain information about what version they are. In other
> words some sort of a header in the binary which contains the RCS version
> number the binary was compiled fr
On Tue, 25 Apr 2000, Wilko Bulte wrote:
>OK. But you do have to uniquely identify the binary that needs to be
>patched. So, my question is when you generate 10x the same binary, will all
>these 10 binaries have the same MD5 checksum? In other words: if people did
>a local buildworld once on a -re
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> OK. But you do have to uniquely identify the binary that needs to be
> patched. So, my question is when you generate 10x the same binary, will all
> these 10 binaries have the same MD5 checksum? In other words: if people did
> a local buildworld once on a
