Re: Modify files on before commit using loginfo?

[Glassmann, Lenny]

I'd like to provide an example of a case where something like this would be
useful.  I want to prevent people from building a program that was compiled
with 2 different versions of a C++ header file.  We already use the cvs
ident command to look for problems like this, but it would be even better to
prevent it in the first place.

It would be great if we could declare a global variable with a name that
contains the header file name and version number, e.g. for version 1.17 of
foo.h,

Extern int foo_h_1_17 = 0;

Then in foo.c, we can define this global variable.  If someone has compiled
some file with version 1.16 of foo.h instead of version 1.17, they will get
a linker error.

CVS has $Id$ and $Revision$ keywords, but they can't be used to build this
variable name.  For one thing, the name can't have dots in it.  Running a
script to modify the file either on checkout or commit would allow us to
declare the variable.

If anyone can suggest a scheme to automate a process like this, it would be
greatly appreciated.

>-- Forwarded mail from address@hidden

Agreed.  Make the user make the change you want committed.  Supply a script
to do it if necessary.  Then use the *info capability to verify that it
was done.

>--- Forwarded mail from address@hidden

>Anders Carlberg <address@hidden> writes:

>> Is it possible to modify the files before they are commited to the
>> repository using loginfo or commitinfo?

>At loginfo time it is already too late, the file has been committed to
>the repository. At commitinfo time, you have access to the server side
>copy of the files (or the original files if in :local: mode), so it may
>be possible to whack in changes. Doing so is a very bad idea as it
>introduces entropy that is not controlled by the user into the process
>of trying to accurately record the state of files that 'worked' for the
>user.

>> How should I do this?

>You should not do it. If you choose to do it, you may find yourself
>in a world of hurt eventually.

>> Is there a file stream I can read and write to?

>Not really.

>> Or should I do this via CVS commands (checking out and commit) (but then
>> the files get a new version? Or?) ?

>CVS is bright enough not to provide for this kind of lunacy/idiocy.

>> Is there anyone that has done something like this?

>Probably, folks have been abusing CVS in ways it was never intended to
>be used for many years now. This does not make it a good idea.

>--- End of forwarded message from address@hidden