[PATCH] importinfo/admininfo
As promised, I've now finally (sorry for the delay) started to work-off my larger CVS patch set for OpenPKG which you can find in original under http://cvs.openpkg.org/openpkg-src/cvs/cvs.patch.rse The first result is a completely worked-off importinfo and admininfo patch against the latest CVS HEAD version of CVS which you can find under http://www.engelschall.com/~rse/cvs/cvs.patch-info.diff and in the attachment to this email. The patch adds two still missing and very important auditing hook facilities to CVS: CVSROOT/importinfo for auditing cvs import operations and CVSROOT/admininfo for auditing cvs admin operations. I was prompted to implement these some years ago when I wrote OSSP Shiela (see http://www.ossp.org/pkg/tool/shiela/ for details) and had to recognize that it still could be circumvented by the two remaining repository-destructive operations cvs import and cvs admin. The patch was adjusted in style (including C89) to now hopefully fully conform to the CVS coding style, and extended with documentation and full test suite additions. It also includes some of the feedback you already gave to Wu Yongwei. It should be now ready for final inclusion into the CVSHome.org CVS sources and become part of the next major CVS release. Please review the patch in detail and give me feedback. If everything is fine, please commit it to the CVS HEAD of CVS and let us proceed to the next possible contributions derived from my OpenPKG CVS patch set. Yours, Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com This patch adds two still missing and very important auditing hook facilities to CVS: CVSROOT/importinfo for auditing cvs import operations and CVSROOT/admininfo for auditing cvs admin operations. Index: man/cvs.1 === RCS file: /cvs/ccvs/man/cvs.1,v retrieving revision 1.35 diff -u -d -r1.35 cvs.1 --- man/cvs.1 19 Mar 2003 21:13:30 - 1.35 +++ man/cvs.1 4 Oct 2003 10:35:47 - @@ -1975,6 +1975,11 @@ $CVSROOT/CVSROOT Directory of global administrative files for repository. .TP +CVSROOT/importinfo,v +Records programs for filtering +.` cvs import +requests. +.TP CVSROOT/commitinfo,v Records programs for filtering .` cvs commit @@ -2017,6 +2022,11 @@ .` cvs rtag operations. .TP +CVSROOT/admininfo,v +Records programs for validating/logging +.` cvs admin +operations. +.TP MODULE/Attic Directory for removed source files. .TP @@ -2108,7 +2118,7 @@ This is the process identification (aka pid) number of the .B cvs process. It is often useful in the programs and/or scripts -specified by the CVSROOT/commitinfo CVSROOT/verifymsg and +specified by the CVSROOT/importinfo CVSROOT/commitinfo CVSROOT/verifymsg and CVSROOT/loginfo administrative files. .TP .SM CVS_RSH Index: man/cvs.5 === RCS file: /cvs/ccvs/man/cvs.5,v retrieving revision 1.6 diff -u -d -r1.6 cvs.5 --- man/cvs.5 17 Apr 2002 19:00:20 - 1.6 +++ man/cvs.5 4 Oct 2003 10:35:48 - @@ -15,6 +15,8 @@ .hy 0 .na .TP +.B $CVSROOT/CVSROOT/importinfo,v +.TP .B $CVSROOT/CVSROOT/commitinfo,v .TP .B $CVSROOT/CVSROOT/cvsignore,v @@ -32,6 +34,8 @@ .B $CVSROOT/CVSROOT/rcsinfo,v .TP .B $CVSROOT/CVSROOT/taginfo,v +.TP +.B $CVSROOT/CVSROOT/admininfo,v .ad b .hy 1 .SH DESCRIPTION @@ -59,6 +63,14 @@ (absolute, or relative to \fB$CVSROOT\fP) for the files they wish to manage with \fBcvs\fP commands. .SP +You can use the `\|importinfo\|' file to define programs to execute +whenever `\|\fBcvs import\fP\|' is about to execute. These programs are +used for ``pre-import'' checking to verify that the imported files are +really ready to be committed. Some uses for this check might be to turn +off a portion (or all) of the source repository from a particular person +or group. Or, perhaps, to verify that the imported files conform to the +site's standards for coding practice. +.SP You can use the `\|commitinfo\|' file to define programs to execute whenever `\|\fBcvs commit\fP\|' is about to execute. These programs are used for ``pre-commit'' checking to verify that the @@ -92,6 +104,11 @@ to a group of developers, or, perhaps, post a message to a particular newsgroup. .SP +You can use the `\|admininfo\|' file to define programs to execute +whenever `\|\fBcvs admin\fP\|' is about to execute. Some uses for this +check might be to turn off administration access to a portion (or all) +of the source repository for a particular person or group. +.SP You can use the `\|rcsinfo\|' file to define forms for log messages. .SP You can use the `\|editinfo\|' file to define a program to execute for @@ -207,7 +224,7 @@ directory of the checked-out module. \fIprog\fP runs with a single argument, the full path to the source repository for this module. .TP -\\fBcommitinfo\fP,
Branch Manager
Title: Message Apologies in advance if this is the wrong mailing list but it's the only one that looked promising. We have abase set of files that we customize on a per-client basis. Each client has a mirror image of the base directory structure. Each client does not have a mirror image of the base files but rather only those files that require customization exist in the client directory tree. Prior to building a client we merge the client tree with the base tree using a simple recursive copy and then build.That simple approach is well organized and effective however there are some drawbacks. This is not the typical branching situation since there will never be any merging of client code back in to the main trunk.There is also resistence to using CVS branches since everybody contributing to the project (content developers, technical writers) must now manage branch labels versus just plopping changes for Acme in the Acme folder. I would really be interested in hearing from anybody who has ideas onmanaginghighly selective client changes for a large number of clients. TIA Rod ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [PATCH] importinfo/admininfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [Note: I'll send Ralf the picky C-style comments in a separate private message.] Ralf S. Engelschall [EMAIL PROTECTED] writes: The first result is a completely worked-off importinfo and admininfo patch against the latest CVS HEAD version of CVS which you can find under http://www.engelschall.com/~rse/cvs/cvs.patch-info.diff and in the attachment to this email. Thank you very much for your time. The patch adds two still missing and very important auditing hook facilities to CVS: CVSROOT/importinfo for auditing cvs import operations and CVSROOT/admininfo for auditing cvs admin operations. I was prompted to implement these some years ago when I wrote OSSP Shiela (see http://www.ossp.org/pkg/tool/shiela/ for details) and had to recognize that it still could be circumvented by the two remaining repository-destructive operations cvs import and cvs admin. I believe it is still possible for a 'cvs import' to destroy important cvs branch and version tags. If the intent is to help lock down the 'cvs import' command, then more work is probably needed... The patch was adjusted in style (including C89) to now hopefully fully conform to the CVS coding style, and extended with documentation and full test suite additions. It also includes some of the feedback you already gave to Wu Yongwei. It should be now ready for final inclusion into the CVSHome.org CVS sources and become part of the next major CVS release. Well, there are a few minor places where you use closely nested braces rather than putting them on a new line by themselves and a few other lines that should probably be reformatted as being too long. However, the majority of the code does match the coding standards and I really appreciate the work you did to adapt your patch and write the documentation and test cases. I will note that the man pages are not the primary reference documentation for cvs, so it would be desirable for you to extend the docuemntation in the doc/cvs.texinfo file as well. Please review the patch in detail and give me feedback. If everything is fine, please commit it to the CVS HEAD of CVS and let us proceed to the next possible contributions derived from my OpenPKG CVS patch set. [I believe that Larry has suggested that a separate importinfo may not be needed and that the existing commitinfo and taginfo scripts should be extended. I will let Larry make his own comments concerning your patch.] My own opinion is that some administrators may wish to impose controls that are orthogonal to normal commits and having a different script allows for more flexibility to the cvs administrator. It may not be argued that it is more complex to use multiple scripts and possibly accidentally introduce different standards for entry into the source base. I have a slight bias toward moving to a new importinfo script to augment what already exists rather than overloading the existing commitinfo with the added state caused by knowing that this is an import over multiple directories and files with two new tags being added to the repository... so, I have a slight bias in favor of your new feature in principle over reworking the commitinfo script. One thing that does concern me is that the tags for a cvsimport do not appear to get passed to either importinfo nor taginfo for checking. If the importinfo feature is to really check what the user is doing, is it not possible that the user is about to destroy a very important release tag that already exists as a side-effect of their import? With regard to the admininfo trigger, I presume that users will either need to be a part of the CVS_ADMIN_GROUP or there will need to be no CVS_ADMIN_GROUP at all in order for the admininfo script to be run. In addition, only those options permitted by UserAdminOptions will get thru. Is that correct? If so, it probably deserves a mention in the doc/cvs.texinfo file. Also, there are many discrete operations possible with 'cvs admin' and they are very different. It is not clear to me how the script would know that a user might be deleting a revision in the file versus changing from -kkv to -kk keyword expansion mode or trying to unlock a revision that had somehow been locked. For example, might it be desirable to ensure that a replacement log message (-mrev:msg) conformed to the same standards as one that was given during a 'cvs commit' operation? It might be that the cvs administrator would need/want the list of switches being passed to the admininfo script. A good design now might really give a cvs administrator more flexibility in what they allow their users to do for themselves. Thanks, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/fw3j3x41pRYZE/gRAjihAKC9seqTw+6DZENyr2FANW/III5umgCfTjjJ nsduP9hdq6sqw1FMzLW9VTA= =UPXD -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED]
CVS screwing up Word documents
Hello: We checked in several Word documents into our CVS. When we check them out, Word gives an error when trying to open them. We have: *.doc -k 'b' in our cvswrappers file in our CVSROOT. Any ides why this is occurring? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [PATCH] importinfo/admininfo
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf S. Engelschall [EMAIL PROTECTED] writes: On Sat, Oct 04, 2003, Mark D. Baushke wrote: Ralf S. Engelschall [EMAIL PROTECTED] writes: The patch adds two still missing and very important auditing hook facilities to CVS: CVSROOT/importinfo for auditing cvs import operations and CVSROOT/admininfo for auditing cvs admin operations. I was prompted to implement these some years ago when I wrote OSSP Shiela (see http://www.ossp.org/pkg/tool/shiela/ for details) and had to recognize that it still could be circumvented by the two remaining repository-destructive operations cvs import and cvs admin. I believe it is still possible for a 'cvs import' to destroy important cvs branch and version tags. If the intent is to help lock down the 'cvs import' command, then more work is probably needed... Can you give more details, please? Why can cvs import still destroy any tags if an importinfo filter would stop processing? My importinfo hook is very early in the cvs import processing and AFAIK there is no repository write access before it. I was under the impression that the importinfo_runproc was running the filter and passing the importinfo_vtag, the repository and the files being imported. Is the vendor branch getting to the script thru some other means? I suppose this is not a big deal as it should only really matter for tags that are for real RCS branches as opposed to CVS magic branches, but I wasn't 100% sure about failure modes... Another fairly minor matter is that the -k options is not known at import time and might be fairly critical to folks that might want the -kb default for 'binary' files to be checked... I find it less important to worry about the -k option on a cvs commit than on an import. However, I suppose that both of them really should be treated the same, so I am just noting in passing that a server on a Windows box may be at more of a disadvantage in understanding how the imported files are to be opened for verification than their non-windows counterparts. [...] I will note that the man pages are not the primary reference documentation for cvs, so it would be desirable for you to extend the docuemntation in the doc/cvs.texinfo file as well. I've looked at the doc/cvs.texinfo file and have not found any chapter which really deals with the info hooks. There are just a few references and small examples at various places for some hooks, but no general documentation on them. So I decided to document them in cvs(5), because there at least mostly all info hooks _are_ already documented. I understand the documentation is light, but just as there is an '@node commitinfo' in doc/cvs.textinfo, there should be one for each of the two new files you are adding. It may not be argued that it is more complex to use multiple scripts and possibly accidentally introduce different standards for entry into the source base. I have a slight bias toward moving to a new importinfo script to augment what already exists rather than overloading the existing commitinfo with the added state caused by knowing that this is an import over multiple directories and files with two new tags being added to the repository... so, I have a slight bias in favor of your new feature in principle over reworking the commitinfo script. Especially, if you change the existing commitinfo script you too easily could break lots of existing tools. Yes, I find this to be a good argument. It remains to be seen if the consensus of the others matches it. One thing that does concern me is that the tags for a cvsimport do not appear to get passed to either importinfo nor taginfo for checking. If the importinfo feature is to really check what the user is doing, is it not possible that the user is about to destroy a very important release tag that already exists as a side-effect of their import? Why are the tags not passed? At least for my importinfo, the vendor-tag is passed as an argument. Without this my OSSP Shiela facility would not be able to control imports to different branches. Hmmm... I didn't notice this and it did not appear in the documentation for how the file is used... With regard to the admininfo trigger, I presume that users will either need to be a part of the CVS_ADMIN_GROUP or there will need to be no CVS_ADMIN_GROUP at all in order for the admininfo script to be run. In addition, only those options permitted by UserAdminOptions will get thru. Is that correct? If so, it probably deserves a mention in the doc/cvs.texinfo file. Correct. My current admininfo is processed _after_ the CVS_ADMIN_GROUP stuff is processed. Good. I thought this was the case, but it should be documented for folks in the man page and cvs.texinfo node on the file. Also, there are many discrete operations possible with 'cvs admin' and they are very different. It is not clear to me how the
RE: CVS screwing up Word documents
Mark: This should not happen if the cvswrappers file has that line and your Word docs have a .doc extension. That is what we have. You can use the log command to verify that the Keyword substitution is set to 'b' for those files. I did that. The keyword substituion is set to kv, which is wrong. Are you using Cygwin by any chance? If so it is possible that you are running into a problem with line ending conversions from Cygwin. Yes, we are using cygwin to tunnel the cvs thru ssh. Do you know how to work around this? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS screwing up Word documents
Neil, If the keyword expansion is not correct for your Word files then one of two things must be happening. Either you are using the -k option with the checkout, add, or update commands or there is something wrong with your cvswrappers file. Make sure that you are not passing a -k flag when checking out or updating files (or using the -k flag on adds) since it becomes sticky when it used with these two commands. Alternatively, specifically use -kb explicitly whenever you are adding binary files such as Word documents. Cygwin programs can operate on files in either binary or text mode as explained in http://cygwin.com/cygwin-ug-net/using-textbinary.html. You might want to try adding tty binmode to your CYGWIN environment variable to ensure that Cygwin programs are always using binary mode. If tty is not set then I think that the Cygwin cvs client might treat standard input and output in text mode rather than binary mode which would corrupt the cvs protocol. Good Luck, Mark - Original Message - From: Neil Aggarwal [EMAIL PROTECTED] To: 'Mark Priest' [EMAIL PROTECTED] Cc: 'CVS-II Discussion Mailing List' [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 9:40 PM Subject: RE: CVS screwing up Word documents Mark: This should not happen if the cvswrappers file has that line and your Word docs have a .doc extension. That is what we have. You can use the log command to verify that the Keyword substitution is set to 'b' for those files. I did that. The keyword substituion is set to kv, which is wrong. Are you using Cygwin by any chance? If so it is possible that you are running into a problem with line ending conversions from Cygwin. Yes, we are using cygwin to tunnel the cvs thru ssh. Do you know how to work around this? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS screwing up Word documents
Mark: The CYGWIN environment variable did the trick. Thank you, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com -Original Message- From: Mark Priest [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2003 9:44 PM To: Neil Aggarwal; 'CVS-II Discussion Mailing List' Subject: Re: CVS screwing up Word documents Neil, If the keyword expansion is not correct for your Word files then one of two things must be happening. Either you are using the -k option with the checkout, add, or update commands or there is something wrong with your cvswrappers file. Make sure that you are not passing a -k flag when checking out or updating files (or using the -k flag on adds) since it becomes sticky when it used with these two commands. Alternatively, specifically use -kb explicitly whenever you are adding binary files such as Word documents. Cygwin programs can operate on files in either binary or text mode as explained in http://cygwin.com/cygwin-ug-net/using-textbinary.html. You might want to try adding tty binmode to your CYGWIN environment variable to ensure that Cygwin programs are always using binary mode. If tty is not set then I think that the Cygwin cvs client might treat standard input and output in text mode rather than binary mode which would corrupt the cvs protocol. Good Luck, Mark - Original Message - From: Neil Aggarwal [EMAIL PROTECTED] To: 'Mark Priest' [EMAIL PROTECTED] Cc: 'CVS-II Discussion Mailing List' [EMAIL PROTECTED] Sent: Saturday, October 04, 2003 9:40 PM Subject: RE: CVS screwing up Word documents Mark: This should not happen if the cvswrappers file has that line and your Word docs have a .doc extension. That is what we have. You can use the log command to verify that the Keyword substitution is set to 'b' for those files. I did that. The keyword substituion is set to kv, which is wrong. Are you using Cygwin by any chance? If so it is possible that you are running into a problem with line ending conversions from Cygwin. Yes, we are using cygwin to tunnel the cvs thru ssh. Do you know how to work around this? Thanks, Neil -- Neil Aggarwal, JAMM Consulting, (972)612-6056, www.JAMMConsulting.com FREE! Valuable info on how your business can reduce operating costs by 17% or more in 6 months or less! = http://newsletter.JAMMConsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
