Re: [Monotone-devel] Keyword substitution?

[Hendrik Boom]

On Wed, Jul 27, 2005 at 10:47:41PM +0200, Richard Levitte - VMS Whacker wrote:
> In message <address@hidden> on Wed, 27 Jul 2005 14:09:32 -0400, Hendrik Boom 
> <address@hidden> said:
> 
> hendrik> Perhaps a revision number could be inserted (if desired)
> hendrik> when a revision is checked in, thather than when it is
> hendrik> exported?  That way the external version will be identical to
> hendrik> the one in the database?
> 
> If done on checkin, it will generate all kinds of problems.  First of
> all, since the revision has a hash of the manifest, which has a hash
> of the file, changing the file will change the hash of the file, which
> will change the manifest, which will change the hash of the manifest,
> which will change the revision, which will change the revision hash
> (ID), so you need to change that in the file...  Now, let's all sing:
> o/~ Neverending sto-ory... o/~

I was thinking of revision numbers for external consumption --
you know, the ones that look like 5.7.-2a-sarge4.6 and such.
These would be chosen by the programmer or release manager,
not computed as a hash, not generated by monotone.
As such, there would be no need to compute a fixed-point
for a hash function.

> 
> hendrik> Or maybe it could be inserted when the file is exported from
> hendrik> monotone to elsewhere, if desired.  And at the same time
> hendrik> create that revision -- with the externally known revision
> hendrik> number -- into the monotone data base, possibly marked as an
> hendrik> exported version?
> 
> Well, substitution could happen on export, as long as the keywords are
> canonicalised back.  If that's to happen, I actually like the
> subversion way, where you have to say explicitely which keywords
> should be expanded.  If monotone is to have keywords, I suggest doing
> it that way (perhaps by creative use of .mt-attrs).

Yes.  I don't want the marker for an insertion into a C program
being recognised in my binary files either.

> 
> Either way, keyword expansion is an error-prone business which
> requires great thought and care, so let's not rush into it.  We have
> bigger issues to deal with, so I suggest we put the keyword thought on
> hold for now.

No need to rush forward with an implementation before the design is done!
But the time to design is now, when we have the time to do it right.
Maybe next year we'll know what we should do!

-- hendrik