[cvsnt] Re: Keyword Expansion Help

[Bo Berglund]

On Mon, 16 May 2005 13:48:29 +1200, "Trevor Leybourne"
<trevor.leybourne at aderant.com> wrote:

>I asked this question about 2 weeks ago, but didn't get any replies so 
>thought I would resend it as I would love some assistance on how I can solve 
>this problem.
>
>
>I have a number of binary files (Oracle Forms and Reports) which will reside 
>in our repository. I want to store the version number or $Id$ string in each 
>file and can do this through a program I have written which is able to read 
>the Oracle files and update inbuilt parameters to store this information (I 
>can't use a normal string replace type function).
>
>How can I specify this in one of the CVSROOT files to perform this function 
>when certain files are committed to the repository?
>
>For example, if a file ending in .FMB, .PLL or .RDF is commited then execute 
>the VersionUpdate.exe program passing the name of the file to update and the 
>new keyword or version string to update with.
>
>I've looked at CommitInfo but it does not provide me with what the new 
>version number for the file will be. LogInfo does provide that information 
>but is it too late at that point? It looks to me like LogInfo is triggered 
>after the file has been written into the repository and therefore I would 
>not be able to update it.
>

I don't think it can be done, at least not easily...
Reasons:
1: At the time commitinfo triggers no processing of the files has been
done so CVS has not calculated the old/new revisions.

2: Your alternative, to parse the files yourself is not really good
since you will have to mimic the processing CVS will do if you exit
with a 0 result.

At the time of commitinfo execution the only thing that has happened
is that the committed files have been coopied to the temp dir along
with the CVS control files. What you presumably could do is to read
the Entries file to get info on the old revision of the files, but how
you could get at the new revision is more difficult. You would have to
take into account such things as being on a branch and possibly forced
revisions on the command line and the like.

But then again, where in the file would you put the data? If you
replace some kind of marker you have put there, then this marker will
be gone from the file and the updated file in the sandbox will no
longer have the marker the next time around...

Finally:
I don't understand what good this is, you are trying to embed CVS
specific administrative info (the revision number) into your file.
Remember the revision number is no *version* as you call it, it is
purely a way for CVS to keep track of its tree. And being this it
should really not be used outside of CVS anyway.
You are probably better of with an Oracle native way of marking the
files instead...


/Bo
(Bo Berglund, developer in Sweden)