Re: Modify files on before commit using loginfo?
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Anders Carlberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Modify files on before commit using loginfo?
Have you considered something like this? Create a special target in your makefile that performs all the auditing of your process that you want. Its prerequisites should be all of the header files you're concerned about. Put it under CVS control and commit it with all of your sources, and apply the necessary verification using the *info hooks. List it in the prerequisite list of all of your first-order derived objects (e.g. your .o files, but it need not actually be used in the recipe). Creating the audit file would be a simple matter of reading the user's environment and running a few simple programs (e.g. cpp and grepping its output for known strings). The verification would be to compare the user's audit file against a trusted template. You could also add more verification into the recipe that builds the audit file, and fail the build if it doesn't match the trusted template. This isn't a foolproof method to prevent the type of error that you describe. Touching the audit file avoids rebuilding it if its prerequisites change. It also causes unneeded compilations by introducing extraneous prerequisites, but this can be improved by writing an audit file for every shippable. --- Forwarded mail from [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Anders Carlberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED] --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Modify files on before commit using loginfo?
Title: Modify files on before commit using loginfo? Hi, Is it possible to modify the files before they are commited to the repository using loginfo or commitinfo? How should I do this? Is there a file stream I can read and write to? Or should I do this via CVS commands (checking out and commit) (but then the files get a new version? Or?) ? Is there anyone that has done something like this? Cheers. /Anders ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Modify files on before commit using loginfo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anders Carlberg [EMAIL PROTECTED] 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. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFAyB3y3x41pRYZE/gRAllYAJ9iWGbA0rTNYuezEkuWjy08X1tp7QCbBQaz YoVnge0+ghix3HB9cZOLhpw= =ccqJ -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Modify files on before commit using loginfo?
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 [EMAIL PROTECTED] Anders Carlberg [EMAIL PROTECTED] 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 [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
