[OpenAFS-devel] openafs 1.5 HP-UX question

[Marcus Watts]

> Date:    Mon, 11 May 2009 02:00:05 EDT
> To:      Marcus Watts <mdw@umich.edu>, openafs-devel@openafs.org
> cc:      jhutz@cmu.edu
> From:    Jeffrey Hutzelman <jhutz@cmu.edu>
> Subject: Re: [OpenAFS-devel] openafs 1.5 HP-UX question
> 
> --On Sunday, May 10, 2009 10:09:02 PM -0400 Marcus Watts <mdw@umich.edu> 
> wrote:
> 
> > A copy of "afs 3.6" from ibm shows this:
> >#           HP92453-02 A.10.0A HP-UX SYMBOLIC DEBUGGER (PXDB) $Revision:
> >#           1.71 $
> > (claims to be "afs3.6 1.53").
> >
> > There is also this web page:
> > http://web.mit.edu/afs/sipb/project/openafs/ibm-src/src/libafsrpc/Makefile
> > showing the same copyright.
> >
> > 	=> pre-cvs transarc/openafs string was probably '1.71'.
> 
> Well, no.  Keyword substitution is not a new feature in CVS; and AFS source 
> has been tracked in RCS since long before HP-UX.  You are unlikely to be 
> able to discover the original value by looking at any version of AFS 
> source, since it was already broken by the time OpenAFS 1.0 was imported 
> into our CVS repository, and you likely don't have access to a repository 
> older than that.  I do, but it's far too old to contain these files, let 
> alone HP-UX 11 support.
> 
> -- Jeff

I first encountered RCS keyword substitution somewhere around 1985,
and "what" even earlier, so yes, I believe I'm somewhat familiar with
the concept.  I also seem to recall working on pts "groups in groups"
and using cvs quite extensively for that.

But I agree - that "1.71" string in transarc 3.6 source is most likely
bogus, and it's not useful to sort out exactly what rcs repository
it might have come from.  That's why I included the "what" strings I
had found via google - presumably those actually *do* come from the
real thing.  Unfortunately there seems to be more than one broken version.

So I hope the interesting question here is what *should* be in there,
if anything.  If the kludge isn't necessary can we just pull it?  If the
kludge is only sometimes necessary, can we put in a configure test to
catch it?  Or document which version(s) of pxdb do not have the problem?
If the kludge is always necessary, do we need to say anything about the
exact version of pxdb at all?  And if we want to be conservative and
change nothing of substance, can we at least remove the $Revision: xxx$ part
and replace it with "some unknown revision" and avoid deluding some future
poor hp-ux person with bogus revision tags?

				-Marcus Watts