I wrote bad comment, how to modify it?
After I made some modification, I commit the changes , but I wrote some error message about the code. How to get rid of it? Thanks Wade ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: I wrote bad comment, how to modify it?
This will help you... http://cvsbook.red-bean.com/cvsbook.html#I%20just%20committed%20some%20files%20with%20the%20wrong%20log%20message -Rohan Wade Yin wrote: After I made some modification, I commit the changes , but I wrote some error message about the code. How to get rid of it? Thanks Wade ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Other cvsweb newbie with problems ...
Omar Florez wrote: I'm using perl v5.8.0, cvsweb-3.0.1-0 and the error message that shows apache is Unrecognized character \xA7 at cvsweb.cgi line 837 are there anyone that can help me please ? Here are my suggestions: 1) Examine the cvsweb.cgi script, using a text editor, and look at line 837. Does it look right, or is it obviously corrupted? 2) Contact a list that deals with cvsweb 3) Give a little more context on the error - what were you doing that caused the error, for example? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Changes made to project
Jim.Hyslop wrote: Murrgon wrote: Hmmm, yeah I think I'm gonna need some different method. The problem is that the machine doing the check for differences does not have the project checked out to a sandbox so doing a diff won't work. rdiff works against the repository without a working copy, and also accepts the -d and -r options. rdiff should do the trick. Thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
how to do an rcs revert?
Given a project a that has the path a/b/c/d and a file a/b/c/d/file1, you check in file1, then make a change, check in the change, then want to revert to the original version, how do you do it? This is like 'cd a/b/c/d ; co -r1.1 file1'. Mike ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: how to do an rcs revert?
Mike wrote: Given a project a that has the path a/b/c/d and a file a/b/c/d/file1, you check in file1, then make a change, check in the change, then want to revert to the original version, how do you do it? This is like 'cd a/b/c/d ; co -r1.1 file1'. Use the -p and -r options: cvs update -p -r1.1 file1 file1 then check it in again. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Identifying the user who tagged some files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Is it possible to identify the user who added some tag? I might add something at taginfo for that, but I haven't seem an indication that the username was sent as a parameter on tagging operations... TIA, - -- Godoy. [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9rqDEzC+baSjBiURAn3mAJwN3HQn3qwSLm8xngAhXJyCCqmTjACgmF5E jbYH6i4/l5hSnhC2bhmtp2A= =VGKT -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
CVS and CMM workflow
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, Do any of you here work in a CMM certified company? I'm working with a company that is going to be certified and I am curious about some procedures to, at first, gather all evidences needed, specially authorization to start the work in some modules and the authorization to commit the changes (commiting is not hard, since there are logs, but the start is more problematic, specially with a very dynamic team). Anybody wanting to chat a little? I can compile the answers and submit a report later to the list, to help other people in the future... Be seeing you, - -- Godoy. [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9rsREzC+baSjBiURAu/AAJ9Y0Pg8RnErmQOpg3UHHv9GigehIQCgmQyA CWziuUgyUT8xY6UFDX4iVbo= =XqIz -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Identifying the user who tagged some files.
At 01:10 PM 7/15/2004, Jorge Godoy wrote: Is it possible to identify the user who added some tag? I might add something at taginfo for that, but I haven't seem an indication that the username was sent as a parameter on tagging operations... Have taginfo execute a script and use $USER ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: binary files bad idea? why?
[ On Monday, July 12, 2004 at 17:10:46 (-0700), Mark D. Baushke wrote: ] Subject: Re: binary files bad idea? why? It is a pity that you didn't bother to read what I wrote and instead ranted on a question that was not asked. Have you been ill? If so, I am sorry to hear it, please get well soon. No, the real problem is you're beginning to get the same disease Paul has suffered from for so many years. You're not seeing the forest for the trees. You concocted a detailed micro-example to illustrate your point without any consideration to the higher level concepts involved or even any analysis of how your example might actually relate to higher level concepts and requirements. I don't think you're even paying proper and full attention to some of the underlying reasons for doing change control in the first place. You're clearly not yet grasping the full impact of what RCS compatability really means and why it is so important to CVS users (not CVS necessarily, but certainly CVS users whether they appreciate it yet or not). You seem to sometimes mime the idea of RCS compatability but you clearly haven't integrated it into your thoughts enough that you can see when and how a propsal wil interfere with, or even completely break, it. Perhaps all of this is my fault for not writing more lucid and detailed descriptions of the ideas I'm trying to get across, but there are only so many hours in the day and even fewer that I can use to enjoy in these pursuits of intellectual discussion in public forums such as this one. Your entire reply to my previous message did not address any of the points or topic of my message That's because what you (and Paul) are suggesting is what can only be called a hack (and in my mind an ugly one at that) which goes in entirely the wrong direction for all these underlying reasons of why any sufficiently aware person would choose to use CVS (or any other RCS-compatible) change control tool in the first place. I'm not going to get sucked into debating artificially concocted examples that ignore the bigger conceptual picture and which also ignore a great many other lower level details as well. I've been trying to _raise_ the level of discussion up to the concepts and requirements where it _must_ occur before anyone can do any sensible functional design or implementation (such as your contrived example attempted to do). If you are not going to even bother to read what I write and not try to read between the lines, you are going to hurt yourself and burst a blood vessel or something... If you are not going to even bother to try to read what _I_ have written and to try to grasp the basic fundamental concepts I'm trying to relate to CVS and to how CVS is, and could be, used, then we're not going to progress at all. You're focusing on the details necessary to prop up your argument and I'm just not going to descend to the level of discussing such details untill well after everyone's come to a consensus about how things can and should work at a conceptual level. Why don't you have a peek again at the discussion on effective ways to use CVS with (La)TeX (or troff or lout or texinfo or whatever) documentation. Embedded in that thread is a hint to just how important it is to work _with_ the ubiquitous nature of line-oriented diff/diff3 algorithms. Stepping back a tiny bit from that thread and considering all the unerlying reasons of why one does change control in such small increments as something like CVS encourages will hopefully also let you get at least a tiny hint of why it's important with any RCS-compatible change control tool that the delta format inside the RCS files be directly and intimately related to the format users see when they do diffs and merges. (hint: unnecessary re-filling of paragraphs, or changes to whitespace, makes diff (and thus RCS and thus CVS) treat any file in a more ``binary'' fashion than necessary, no matter how fundamentally text (line oriented) it appears to be -- I learned this way back in the very early 1980's and I thought this was now such a mantra amongst users of all version control tools that it didn't need saying any more, but obviously that's not yet true) Now if you (or Paul) personally don't want to use an RCS-compatible repository for whatever reason(s) then you don't have to -- as you full well know there are quite a good number of other tools out there already that use other database formats that are more effective for the purposes of pure delta compression (e.g. xdelta) and which always go to the trouble of re-creating all file revisions every time they're needed in order to do any and all presentation-level diffing and merging. One of those tools might already have the capability of using user-specified diff and merge tools for a specified file, file type, or revision set or whatever is appropriate for their model However keep in mind that CVS is today an RCS-compatible change control tool and that this relationship is
Re: Authentication without clear password on the network
BTW, I really do not appreciate your use of a bogus e-mail address, especially when you give no hint as to how a human might concoct a valid e-mail address for contacting you. This forum is primarily a mailing list, not a newsgroup. [ On Tuesday, July 6, 2004 at 12:42:33 (+0200), Yves Martin wrote: ] Subject: Re: Authentication without clear password on the network My constraints are oriented to reduce administrative tasks: - no system user on the UNIX server (there is no need for CVS features indeed - only the log name should be kept for the author field in RCS files) You cannot, by definition, have any real security in your audit trail unless the identities recorded therin are unique _system_ level identities that your authentication system can verifiably be shown to have successfully authenticated and authorized to use the service being audited. CVS and RCS underneath it were desgined to work within the unix security model where each user has a unique system identity. Secure network access to any CVS repository relies on the fact that the client and server hosts can securely communicate to each other the identity of a an authenticated and authorised user. Without this trust, e.g. as it is established by properly used SSH, there is no accountability in the CVS repository being accessed. No use of cvspserver can ever provide any sufficient level of accountability, especially not to anyone who would be concerned with passwords being used in the clear on the network. As far as I'm using the PAM SMB only for the CVS authentication, I do not break the UNIX security. The virtual 'cvs' user only access CVS files. In fact there is no human user connected to the machine but only a client/server CVS service. There is no security in having one authorisation service hand an identity over to another if the latter has no concept of that identifier bbeing a system identity it would recognize and that it could trust had been authenticated, regardless of whether the handover of this identifier can be done securely or not. Current status: - The CVS server is used only in the enterprise network. So there is no need to be so secured but it is better that passwords are not sent as clear text (pserver currently !). 82% of all security incidents are internal. :-) My objections about SSH: - SSH needs a system user per human user and it is too much job to maintain. That whole statement is self-contradictory and the very idea behind it is incomprehensible to me. Obviously SSH needs unique system identities per human users -- that's its primary purpose and it does in fact conform to the unix security model it operates within. If you think maintaining account information for system users is too much work then why are you bothering with any security at all!?!?!?!? - SSH needs to generate certificats and install public keys. It is the only way to use SSH with WinCVS - another too much job for users. Huh? Not the way I use it. :-) My issue now concerns clear text passwords on the network. Ah, so you are worried about security on the enterprise intranet. ;-) (as you well should be! :-) -- Greg A. Woods +1 416 218-0098 VE3TCPRoboHack [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED] Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Identifying the user who tagged some files.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 15 July 2004 14:20, Frederic Brehm wrote: At 01:10 PM 7/15/2004, Jorge Godoy wrote: Is it possible to identify the user who added some tag? I might add something at taginfo for that, but I haven't seem an indication that the username was sent as a parameter on tagging operations... Have taginfo execute a script and use $USER I wasn't sure if it was available, it didn't seem to be from the taginfo text. Thanks. It will help for the purposes we are needing it. Be seeing you, - -- Godoy. [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA9vbAEzC+baSjBiURAg0xAJ9BdyQmnocDFpdtU0st4jJcQxOO2QCfRaI8 YU9fZLKj5Kn1Lqvut6VZ7TE= =/uox -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Ristricting access to CVSROOT....
This may have been asked before; however, I cannot find the answer anywhere. We are trying to restrict access to CVSROOT directory such that only a few can make changes to it and all other can checkout only to read. How can this be done? Any help is appreciated. Thanks Hamid Ghassemi ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Ristricting access to CVSROOT....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamid Ghassemi [EMAIL PROTECTED] writes: This may have been asked before; however, I cannot find the answer anywhere. See https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC169 https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in?rev=HEAD We are trying to restrict access to CVSROOT directory such that only a few can make changes to it and all other can checkout only to read. How can this be done? Have the commitinfo script have an entry for CVSROOT which runs a script. The script returns a zero exit code when $USER is in the allowed list and a non-zero code when $USER is not in the list. Look at contrib/cvs_acls in a tree where you built cvs 1.11.17 for ideas or https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in?rev=HEAD -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA9xWw3x41pRYZE/gRAn/pAJ9KEaJZw3xoKcrLfEDe9nwyNPMiggCfYLeU Duoi9VpHwMOa4kiu7XW1jtc= =zRva -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Ristricting access to CVSROOT....
I enhanced the original contrib/cvs_acl: https://ccvs.cvshome.org/issues/show_bug.cgi?id=170 Although it's not yet part of the regular distribution, you may want to take a look. pc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark D. Baushke Sent: Thursday, July 15, 2004 4:39 PM To: Hamid Ghassemi Cc: [EMAIL PROTECTED] Subject: Re: Ristricting access to CVSROOT -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hamid Ghassemi [EMAIL PROTECTED] writes: This may have been asked before; however, I cannot find the answer anywhere. See https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC169 https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.i n?rev=HEAD We are trying to restrict access to CVSROOT directory such that only a few can make changes to it and all other can checkout only to read. How can this be done? Have the commitinfo script have an entry for CVSROOT which runs a script. The script returns a zero exit code when $USER is in the allowed list and a non-zero code when $USER is not in the list. Look at contrib/cvs_acls in a tree where you built cvs 1.11.17 for ideas or https://ccvs.cvshome.org/source/browse/ccvs/contrib/cvs_acls.in?rev=HEAD -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFA9xWw3x41pRYZE/gRAn/pAJ9KEaJZw3xoKcrLfEDe9nwyNPMiggCfYLeU Duoi9VpHwMOa4kiu7XW1jtc= =zRva -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
