users of mcvs?
hi all, just wanting to find out how many people are using mcvs and what their experiences have been? i'm considering using it and wanted to get a feel for whether there is any community for it. cvs has many flaws, but they are overcome in large part by the community activity on this newsgroup. cheers, matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using cvs to contol system files
Am 23.10.2002 um 19:05 Uhr -0400 schrub Greg A. Woods: RCS is simple to use and gives you version control with few commands to know. I concur 100% I have in the past devised procedures and processes to use CVS to manage system configurations (which ended up having to be much more complex than vi1pdqyo02 was proposing), but I would not do so ever again without using something like GNU Cfengine to do the work and then just use CVS to manage the cfengine inputs. I use cvs for some system files/scripts that I use on several machines, but not with the target directory (/etc, /usr/local/sbin or whatever) as a sandbox. Instead, I add a Makefile so that a 'make install' places the file(s) with permissions set up properly. The files carry a dire warning in the head that any local changes will be wiped out with the next update. hauke -- Hauke Fath /~\ The ASCII Ribbon Campaign tangro software components gmbh \ /No HTML/RTF in email D-69115 Heidelberg X No Word docs in email Ruf +49-6221-1333-60, Fax -621 / \ Respect for open standards ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to set CVS be the reserved checkout mode only?
--- LIU,SHI-ZHOU (HP-China,ex2) [EMAIL PROTECTED] wrote: CVS server version:1.11.2 on HP-UX 11i CVS client: Win CVS 1.3.8.1 on Win2K I'd upgrade the client to be able to take advantage of some newer commands (eg cvs edit). How to set CVS be the reserved checkout mode only? I mean that if one checkout a file and edit it, before he/she commit it, other can't edit the file. CVS doesn't have reserved locks. What you can do, though, is to take a look at the advisory locks patch available at SourceForge under project RCVS. It'll pretty much give you what you want except that, if a developer doesn't follow the rules (ie doesn't do cvs edit -c) or forces an edit (ie does cvs edit -f), they'll be able to edit the file. The advantage is that, assuming users have edit -c in their ~/.cvsrc files, they'll be notified of someone else's edit before going ahead with cvs edit -f if they so choose. Now, we use the rcslock.pl file according to the book: Version Management with CVS for CVS 1.11.2 by Per Cederqvist et al And run the command cvs admin -l, but thus make no one can commit any file. If i run the command cvs admin -L, when one editing a file, other also want to edit the file, it will give out the message: IMHO, using cvs admin should be avoided as much as possible since it's a tunnel to the underlying RCS implementation. HTH, Noel __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 08:15:30AM -0400, James Hughes wrote: Nick Patavalis wrote: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? cvs status -v will provide much (all?) of the above. No it won't! I have to know to *which* file to run cvs status in order to get the info I want. And depending on the tag I'm interested in, it might not be sufficient to do cvs status on one file alone! Take for instance this very real example (my source-tree is a linux-kernel): cvs status -v Makefile === File: Makefile Status: Up-to-date Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: T10 (revision: 1.1.1.2) T9 (revision: 1.1.1.2) T8 (revision: 1.1.1.2) T7 (revision: 1.1.1.2) T6 (revision: 1.1.1.2) T5 (revision: 1.1.1.2) T4 (revision: 1.1.1.2) T3 (revision: 1.1.1.2) T2 (revision: 1.1.1.2) T2 (revision: 1.1.1.1) T1 (branch: 1.1.1) and try to answer: which tag represents the most recent vendor-branch import? /npat -- I xeroxed a mirror. Now I have an extra xerox machine. -- Stephen Wright ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
Nick Patavalis wrote: Is there any way to get, via a script of something, information about the tags in a CVS-controlled tree? I want for example to answer the questions like the following: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? cvs status -v will provide much (all?) of the above. James etc /npat ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Have CVS perform actions on all files before checking in?
Is it possible to have CVS perform some type of action on types of files before checking it in? I'd like to configure our server for all java and C++ code to do some nicetys, like strip out ^M's and replace bloody tabs with spaces where people put them in. Rather than having the commitinfo hook modify the files, just have it reject the checkin until the files fit the coding standard. Or have an alias or ~/bin/cvs wrapper script catch cvs commit calls and do your sed, perl, etc stuff there. That way you can modify the local sandbox files before they are sent to the repository, and your working copy will match the new repository version. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
Nick Patavalis wrote: On Thu, Oct 24, 2002 at 08:15:30AM -0400, James Hughes wrote: Nick Patavalis wrote: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? cvs status -v will provide much (all?) of the above. No it won't! I have to know to *which* file to run cvs status in order to get the info I want. And depending on the tag I'm interested in, it might not be sufficient to do cvs status on one file alone! Take for instance this very real example (my source-tree is a linux-kernel): cvs status -v Makefile === File: Makefile Status: Up-to-date Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: T10 (revision: 1.1.1.2) T9 (revision: 1.1.1.2) T8 (revision: 1.1.1.2) T7 (revision: 1.1.1.2) T6 (revision: 1.1.1.2) T5 (revision: 1.1.1.2) T4 (revision: 1.1.1.2) T3 (revision: 1.1.1.2) T2 (revision: 1.1.1.2) T2 (revision: 1.1.1.1) T1 (branch: 1.1.1) and try to answer: which tag represents the most recent vendor-branch import? easy follow the magic vendor branch 1.1.1.x, T10 is probably the tag that represents the most recent vendor-branch import. now the 'T2 (revision: 1.1.1.2)' and 'T2 (revision: 1.1.1.1)' looks funny, did not think you could apply the same tag to two revisions, but the last import in which the file _changed_ was T2 (revision: 1.1.1.2). A file with a richer import change history would have made this exercise more fun. OK, wait a second...I see why you chose this file...I can not be SURE that the tag was applied during an import, I only assumed it was because it followed the form of the ones used for import, and I believe than any sane (or one who wanted to stay that way) person would use a different form of tag for their own work than they did for imports. I would need at least one more set of history to figure it out for sure. You got me. there are however tools that can help. broken record, Yep that's right I am about to mention cvs2cl.pl again. (can't help it, I like it :) http://www.red-bean.com/cvs2cl/ and FLUFFY has began to do maintenance and is keeping it on cpan (so far looks like he has added an ignore_tags mod) http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ If you run 'cvs2cl.pl -r -t -b' in your sandbox and look for the tags, found with above cvs status, you will find to which files (and when iff at least one file changed) a tag was applied. and if all the files tagged at that time have the import 'magic' revision scheme, the tag is most likely an import one. Now I know why I have a file that gets updated and tagged by the script I hand apply tags with, it keeps me sanER, I know which are mine and which are vendor/other people. branch stuff seems a little tougher and as I don't have other than the vendor branch to check I can't test to give you any pointers (other than figure out what the ''magic'' revision stamp looks like). It might be posible to use the XML output to have a machine parse it out. -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Set lock to strict
--- Alejandro_Gómez [EMAIL PROTECTED] wrote: Ppl, I need to set strict locking on my repository... Why? Are you able to use the advisory locks patch available at SourceForge under project RCVS? Noel __ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: using cvs to contol system files
[ On Thursday, October 24, 2002 at 11:48:26 (+0200), Hauke Fath wrote: ] Subject: RE: using cvs to contol system files Am 23.10.2002 um 19:05 Uhr -0400 schrub Greg A. Woods: RCS is simple to use and gives you version control with few commands to know. I concur 100% I have in the past devised procedures and processes to use CVS to manage system configurations (which ended up having to be much more complex than vi1pdqyo02 was proposing), but I would not do so ever again without using something like GNU Cfengine to do the work and then just use CVS to manage the cfengine inputs. I use cvs for some system files/scripts that I use on several machines, but not with the target directory (/etc, /usr/local/sbin or whatever) as a sandbox. Instead, I add a Makefile so that a 'make install' places the file(s) with permissions set up properly. The files carry a dire warning in the head that any local changes will be wiped out with the next update. Yes, that's what I meant by procedures and processes :-) It's a major nightmare to re-invent something that ends up being very much like cfengine without initially planning to go that far though. -- Greg A. Woods +1 416 218-0098;[EMAIL PROTECTED]; [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; VE3TCP; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 09:10:30AM -0500, Todd Denniston wrote: Nick Patavalis wrote: Take for instance this very real example (my source-tree is a linux-kernel): cvs status -v Makefile === File: Makefile Status: Up-to-date Working revision:1.1.1.2 Wed Oct 23 16:20:33 2002 Repository revision: 1.1.1.2 /home/npat/new_kernel/cvsroot/arm-linux/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: T10 (revision: 1.1.1.2) T9 (revision: 1.1.1.2) T8 (revision: 1.1.1.2) T7 (revision: 1.1.1.2) T6 (revision: 1.1.1.2) T5 (revision: 1.1.1.2) T4 (revision: 1.1.1.2) T3 (revision: 1.1.1.2) T2* (revision: 1.1.1.2) T2 (revision: 1.1.1.1) T1 (branch: 1.1.1) and try to answer: which tag represents the most recent vendor-branch import? easy follow the magic vendor branch 1.1.1.x, T10 is probably the tag that represents the most recent vendor-branch import. No, as a matter of fact it's T2* ! now the 'T2 (revision: 1.1.1.2)' and 'T2 (revision: 1.1.1.1)' looks funny, Ok, this is a typo (I obviously edited the TAG names!). I 've flagged the second T2 as T2* OK, wait a second...I see why you chose this file...I can not be SURE that the tag was applied during an import, I only assumed it was because it followed the form of the ones used for import, and I believe than any sane (or one who wanted to stay that way) person would use a different form of tag for their own work than they did for imports. I would need at least one more set of history to figure it out for sure. You got me. Yep! That's the point. Yep that's right I am about to mention cvs2cl.pl again. Looks helpfull, I 'll try it, but what I would like is a tool that produces an output like this: *Trunk* TAG1 TAG2 Branch0 TAG4 TAG5 Branch1 TAG6 TAG7 Branch1_0 TAG8 TAG9 Branch3 TAG10 or something similar. /npat -- In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams, The Hitchhiker's Guide to the Galaxy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
Nick Patavalis wrote: What tags exist, listed in chronological order? What are the names of the tags corresponding to vendor-branch imports, in chronological order? What tags exist in a specific branch? Your questions are mostly unanswerable. Tags are tags -- CVS keeps no record of whether a tag was created by import or a tag command. Likewise, CVS keeps no record of when a tag was applied. And don't forget that tags are per-file: tag A in file1 may well have been applied by a different person at a different time using a different command than tag A in file2. -Larry Jones Somebody's always running my life. I never get to do what I want to do. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info about tags
On Thu, Oct 24, 2002 at 09:24:41AM -0700, Johnson, Susan wrote: Nick, I would need a tool like that too. People have pointed me to winCVS (windows tools) but I really want a command-line-based output. Looking arround I found a very interesting little perl program. I's called cvs-exp, its written by Sitaram Iyer [EMAIL PROTECTED], and can be found at: http://www.cs.rice.edu/~ssiyer/code/cvs-exp/ It's not very sophisticated (you cannot actually query about the global repository status), but it does produce a tree like the one I was looking for. See for example the output of a test-run at one of my repositories: $ cvs-exp.pl arm-linux 2 /dev/null HEAD |- [VANILLA_ARM] 9241 files | |- R2_4_5_RMK2_NP1 9198 files | `- R2_4_5_RMK7_NP1 9231 files |- clean_arm 9241 files |- DECON_20010719 9243 files |- PRE_MODEMCTL_PATCH 9243 files |- POST_MODEMCTL_PATCH 9243 files |- POST_MODEMCTL_PATCH1 9243 files |- POST_MODEMCTL_PATCH2_RMKFIX 9243 files `- LATEST_KERNELS_EXP 9258 files Nice huh? /npat -- Hey, maybe I could apply for a saint-hood from the Pope. Does somebody know what his email-address is? I'm so nice it makes you puke. -- Linus Torvalds ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to set CVS be the reserved checkout mode only?
LIU,SHI-ZHOU (HP-China,ex2) [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Hi there, CVS server version:1.11.2 on HP-UX 11i CVS client: Win CVS 1.3.8.1 on Win2K How to set CVS be the reserved checkout mode only? I mean that if one checkout a file and edit it, before he/she commit it, other can't edit the file. Investigate the watch, edit, unedit, watchers and editors commands. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Set lock to strict
Ppl, I need to set strict locking on my repository... I´ve added -I option on the line invoking cvs on xinetd.conf... That´s right? Is this enogh? TIA Alejandro Gómez IT Services Lempert S.A. Donaciano del Campillo 2068 Cerro de las Rosas (X 5009 JRZ) Córdoba - Argentina ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Have CVS perform actions on all files before checking in?
Schoep, Grant @ STORM writes: Is it possible to have CVS perform some type of action on types of files before checking it in? One used to be able to use -t/-f wrappers to do that, but they never quite worked right and no one has gotten around to fixing them, so they've been disabled for quit some time. If anyone is looking for a project... -Larry Jones In my opinion, we don't devote nearly enough scientific research to finding a cure for jerks. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Per-modules readers/writers ?
Hello there, Searched some of the archives but came up empty. I don't think it's supported, but I'm mainly asking to see if this will ever be implemented in the future. Basically, I'm wondering if there's any way to limit read/write access to a repository on a modular level, that is, some users mapped in $CVSROOT/CVSROOT/passwd will have read or write access to some modules, while other users will have it for others. I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. With a fairly large repository, administration of large groups of users for a large number of modules can become a nightmare if done on the filesystem level without ACLs. I'd rather have one system user that a great number of developers are mapped to as virtual users, rather than creating a new user or group for each project's members to access the repository with. If not, and I wanted to write a patch to add this feature, what would be the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ [readers,writers] or have permissions defineable in each module directory such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I believe the second choice reduces overhead as the lookups could be done on modular files rather than the global readers/writers files which could tend to become very large). Unless, of course, there's a better way to do what I want it to do, and not on the filesystem level... : ) Thanks in advance, David R. Chase College of Computer Science Northeastern University, Boston ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Per-modules readers/writers ?
If not, and I wanted to write a patch to add this feature, what would be the best way to do it? My two bits...move CVSROOT and all its contents into normalized SQL tables. Not a trivial patch, but it would open up whole new doors for manipulating, querying, and accessing the repository (not to mention transactions and triggers!) Yes, this would likewise close some doors for those who like direct access to the raw RCS metadata files. But anyone conversant in sed or perl should have little trouble mastering SQL, anyway... /troll -Mark Z ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Info about tags
From: Nick Patavalis [mailto:npat;inaccessnetworks.com] Looking arround I found a very interesting little perl program. It's called cvs-exp, it's written by Sitaram Iyer [EMAIL PROTECTED], and can be found at: http://www.cs.rice.edu/~ssiyer/code/cvs-exp/ That is cool. Thank you for pointing that out! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Per-modules readers/writers ?
David R. Chase writes: Basically, I'm wondering if there's any way to limit read/write access to a repository on a modular level, that is, some users mapped in $CVSROOT/CVSROOT/passwd will have read or write access to some modules, while other users will have it for others. I'm mainly trying to obtain finer granularity access control via pserver (or other remote access) authentication rather than via the filesystem's uid/gid and related permissions. With a fairly large repository, administration of large groups of users for a large number of modules can become a nightmare if done on the filesystem level without ACLs. I'd rather have one system user that a great number of developers are mapped to as virtual users, rather than creating a new user or group for each project's members to access the repository with. I strongly suggest using the filesystem's uid/gid and related permissions. Assign a group for each set of modules that require the same access permissions, assign a unique uid to each user (for traceability), and assign each user to as many groups as necessary. If not, and I wanted to write a patch to add this feature, what would be the best way to do it? Have module-permissions defined in $CVSROOT/CVSROOT/ [readers,writers] or have permissions defineable in each module directory such as $CVSROOT/module-name/config-dir/[readers,writers] ? (personally, I believe the second choice reduces overhead as the lookups could be done on modular files rather than the global readers/writers files which could tend to become very large). This is a very bad idea -- CVS is a version control system, not a security system. Using it to implement security is a sure route to exploitable vulnerabilities (witness pserver). -Larry Jones I hope Mom and Dad didn't rent out my room. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
