RE: Permission denied when using CVS remotely
Hi, I upgraded to cvs 1.11, because that was what was lying around. This gave me indeed a better error message: $ cvs -t update cvs update: notice: main loop with CVSROOT=pp4:/usr/local/cvsroot - Starting server: rsh pp4 cvs server cannot create_adm_p /tmp/cvs-serv24426/PPhead Permission denied So, Derek, yes, it was /tmp. But what should I do about it? On my Linux server parapet, I get the following for ls -l / drwxrwxrwt 10 root root 4096 Jun 4 13:11 tmp/ (where apparently the t means 'sticky bit' saying that non-owners can't delete a file in that directory). From my client, I tried: kris@PETNT1 ~/pp4/parapet $ rsh parapet mkdir /tmp/testdir kris@PETNT1 ~/pp4/parapet $ rsh parapet touch /tmp/bla This worked without problems, as shown by ls -l /tmp on parapet: -rw-r--r--1 kris method 0 Jun 4 13:22 bla drwxr-xr-x2 kris method 4096 Jun 4 13:22 testdir/ Any suggestions? Kris PS: I'm upgrading my server to 1.11.1p1 now. Don't think it will help though. From: dprice [mailto:dprice]On Behalf Of Derek R. Price Kris Thielemans wrote: I've set -up CVS on our Linux system (SuSE 6.3,cvs 1.10.7). It all works fine. Now I'm trying to access the archive remotely. I try this from both a Sun (solaris 2.7, cvs 1.10.7) and NT (4.0 sp5, using the cvs version 1.11 distributed with cygwin). I get Permission Denied error messages when I try certain things, while it These error messages are tough for me to interpret as well, but the /tmp directory would be my first suspicion. Check your /usr/local/cvsroot[/module[/...]] and any LockDir you may have set as well. Upgrading your server to 1.11.1p1 (available from http://cvshome.org ) might help matters as well. Many error messages have been improved and many bugs have been fixed in the year or two since 1.10.7 was current. Derek ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Permission denied when using CVS remotely
PS: I'm upgrading my server to 1.11.1p1 now. Don't think it will help though. exactly the same error message as with 1.11 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
setuid failed
Hi, I am running CVS on Linux in pserver mode with clients connecting using WinCVS 1.2. cvs is running under inetd as user 'cvs' although changing this to root has no effect. The cvs repository is owned by user 'cvs' and group cvsusers. The permission look correct. CVS is version 1.10. When a user who is a member of cvsusers tries to commit a file it fails with the message setuid failed: Operation not permitted cvs commit: authorization failed: server zoot rejected access to /home/src for user testuser Does anyone know what is actually happening here what setuid is being attempted? The documentation tells me cvs doesn't/can't use setuid and the binary does not have the setuid bits set. If I set the user to become user cvs or root via the passwd file it works so I guess it must be a permission somewhere. The user testuser in this example has access to all the directories via the group membership. Could any replies copy me via email as I can't get usenet access here. Many thanks, Ian Packer. EDS EMEA Web Hosting Tel. +44-208-754-4904 Dial 8-939 4904 Fax +44-208-754-4398 Dial 8-939 4398 Mobile +44-777-5992836 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and assesment
Larry Jones wrote: Thomas Tuft Muller writes: I imagine a scenario where each programmer is forced to check in once a week (preferrably with a specific tag indicating that the files are possibly untested/uncompilable). Proper scripts could analyze the code regarding inter alia number of lines/words/bytes, commenting, commenting rules, coding-rules, class cohesion, method-length, class-length, parameter names, variable names, etc, etc. In addition the scripts should also take into account the state of the archive last time the scripts were run, and analyze/provide statistics about the change. Combined with a weekly/monthly submitted timeplan from the programmers, this could be a valuable tool for managers to see the overall as well as individual progress/quality. Does such analying scripts exist for the CVS archive format? I sincerely hope not. -Larry Jones Hmph. -- Calvin Sorry to spoil your day Larry, but such scripts do exist (some managers still do not understand that Source Lines Of Code [SLOC] is only useful with Xlib and raw C, but not Motif or GTK and C++ or java). I will however only give you the first line of such an abomination that I have been forced to live under: cvs checkout -r HEAD -p $MODULE_NAME 2/dev/null $TMP_FILE2 It's up to you to determine what kind of tyrannical analysis of $TMP_FILE2 you want to do with a FORTRAN program or perl script. -- __ Todd Denniston, Code 6067, NSWC Crane mailto:[EMAIL PROTECTED] 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 The opinions expressed here are not sanctioned by and do not necessarily represent those of my employer.
RE: CVS and assesment
Todd Denniston wrote: | I will however only give you the first line of such an | abomination that I have | been forced to live under: | cvs checkout -r HEAD -p $MODULE_NAME 2/dev/null $TMP_FILE2 | | It's up to you to determine what kind of tyrannical analysis of | $TMP_FILE2 you | want to do with a FORTRAN program or perl script. I fail to see why some(?) programmers are so reluctant to have their work analyzed and assessed. I'm a programmer myself, and I'm pretty sure that such a tool could benefit good programmers and maybe expose the bad seeds. Sound competion with fellow workers has never hurt anyone. I mean, a lot of employees out there have their work scrutinized and analyzed every day. Why should we be any different? Do we think we are irreplaceable no matter how much and what we actually do? Programmers constitute a very arcane society and I think a lot of companies would like to be able to assess the quality of the Software Development department as well as they do for other departments. The problem is that Software Quality is an understatement in a world where extreme programming emerges as the prevalent development process. I think (good) programmers should be the first in line for deploying tools and processes for assessing their own work. Or are we too scared? -- Thomas * Copyright ERA Technology Ltd. 2001. (www.era.co.uk). All rights reserved. Confidential. No liability whatsoever is accepted for any loss or damage suffered as a result of accessing this message or any attachments. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: setuid failed
Packer, Ian writes: setuid failed: Operation not permitted cvs commit: authorization failed: server zoot rejected access to /home/src for user testuser CVS in pserver mode always tries to setuid to the actual user. That only works if CVS is running as root or is already running as the actual user. If you don't want to run CVS as root from inetd, then you have to use the $CVSROOT/CVSROOT/passwd file to map every valid user to the userid you're running CVS as. -Larry Jones Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Lots of modules need merging
Hi all, Bit of a nightmare one here... We've had a developer working here in the past who used to check out code, go home, restructure stuff add stuff, delete stuff, and then get back and think hmm stuff that and rather than commiting the code, he could create a new module. We therefore have project, project1, project2, project3, and project4, all of which are later stages of the same project, and all of which have a few weeks worth of version information in them. The thing i want to try to do is to pull them all into one module, 'project', with using tags to mark each position. If the version information in each module can bekept, that will be ideal, but i guess if not we /could/ live without it... Does anyone have any idea how i could go about doing this? just to clarify they are like: cvs checkout project4 to get them, so different modules of the same repositry. some things have changed, some just added or removed between versions. Doesnt matter about tracking file moves, that would just be a nightmare Thanks in advance for any bright ideas! -- Steve Smale Tel : 07050 610146 SMS : 82668 349 2317 Fax : 08700 522389 Email : [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS and assesment
I fail to see why some(?) programmers are so reluctant to have their work analyzed and assessed. I'm a programmer myself, and I'm pretty sure that such a tool could benefit good programmers and maybe expose the bad seeds. Sound competion with fellow workers has never hurt anyone. I mean, a lot of employees out there have their work scrutinized and analyzed every day. Why should we be any different? Do we think we are irreplaceable no matter how much and what we actually do? I think that point is that a script which did what you mention both encourages bad practices and creates poor metrics. programmer is forced to check in once a week (preferrably with a specific tag indicating that the files are possibly untested/uncompilable). I have a hard and fast rule that programs checked into a repository are tested and compilable. You dis Extreme Programming in your message, but the key quality control assessment in XP is that at any given point, the system be buildable and runnable, albeit not with complete functionality. All hell would break loose in our development environment if people were checking in code that didn't compile or wasn't tested. Properscripts could analyze the code regarding inter alia number of lines/words/bytes, the scripts should also take into account the state of the archive last time the scripts were run, and analyze/provide statistics about the change. What would be the purpose of these metrics? What quality increases could such statistics provide? commenting, commenting rules, coding-rules, class cohesion, method-length, class-length, parameter names, variable names. I will agree that it might be good to have a wrapper script or tool which warned of these issues BEFORE the changes were committed. Better yet, even, to run such a tool prior to CVS's involvement. Having a developer check in potentially bad code so that another party can judge how good a developer he/she is runs counter to how I feel a good software development process should operate. Jer Smith ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: how to 'lock down' a branch?
Shubho, Sometime ago, I posted patches by John Cavanaugh that can be used for branch locking. The patches are for version 1.11 of CVS but work for the most current version as well. One chunk of the patch will fail because a file has been removed (actually, merged into another), but I have verified that this causes no problems. If you'd like to have a look at the patches, search for my name in the mail archive and you should be able to find them. The patches include updates to the texinfo file which describe the new functionality. After you've patched and built, do a search of the cvs info files for AlternateInfo to get info on the new functionality. Basically, the patch causes more info, including branch name, to be passed to your commit info script. Included with the patches, is a perl script that can be specified in your commitinfo file to implement branch locking. Chuck -Original Message- From:Shubhabrata.Sengupta [mailto:[EMAIL PROTECTED]] Sent:Tuesday, May 29, 2001 10:18 PM To: Harald.Kucharek; info-cvs Subject: Re: how to 'lock down' a branch? Ah! well - to prevent users from mistakenly doing checkins to a branch, along which you do not want any development to happen. This happens especially in large, geographically distributed teams when people tend to forget that checkins are not permitted along certain branches for various reasons - like product released from that branch is End-of-Lifed or that branch was created to do some experimental coding on a particular module etc. There possibly are various ways of spreading this information among the team members and have other methods of enforcing them - but locking down branches happens to be a very convenient one. Thanks Shubho -Original Message- From: Harald Kucharek [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, May 29, 2001 7:58 PM Subject: Re: how to 'lock down' a branch? Kevin Yang wrote: Hi, Can I 'lock down' a branch in cvs? I need to do it so no check-ins can happen to a release branch. It basically becomes a 'read-only' branch. Thanks, Kevin Why do you want to have this? Usually, when you make a release, you tag the current state of the branch so you can revert to the release state whenever you want. But you keep it accessible in case you have to do and check-in some bugfixes. Harald -- iXpoint Informationssysteme GmbH # Daimlerstr. 3 # Harald Kucharek 76275 Ettlingen # [EMAIL PROTECTED] Tel/Fax +49 7243 3775-0/77# www.ixpoint.de ___ 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: CVS GUI (Solaris 2.8)
Howard Zhou wrote: Hi, Derek, Do you know which CVS GUI can be customized easily? It seems to me that it's tkCVS but I just want to confirm. Also do you have any comparison on these GUI packages such as proscons? Not really. I can tell you from experience that jCVS could be a bit slow but was fully featured. I haven't used tkCVS in years but when I did, it was still underfeatured. I just saw an email on [EMAIL PROTECTED] that a new version has been released though. It might be worth checking out or asking about on that mail list. You're probably correct about tkCVS being the easiest to customize. It is a script after all. Since it execs an external CVS executable, it's probably also the easiest to keep up to date with the most recent release of the CVS command line tool. gCVS is probably fastest, of course. I'm guessing it is all in C and has the CVS client code built in. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Those who make peaceful revolution impossible will make violent revolution inevitable. -- John F. Kennedy ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and assesment
A couple of the contributors to this thread seem to assume the following: - Checking in untested code is bad. - Running metrics automatically, whatever they are, is bad. I disagree. Metrics, like any other tool, have their good and bad sides. They must be chosen carefully and their results must be interpreted properly. And several good metrics must be used to offset efforts to manipulate them. Programmers, as both victim and implementor of these tools, must make sure that these tools are used properly by their audience and that their capabilities meet their expectations (or vice-versa). As for checking in bad code, well, there are ways of handling that. One is to track sufficient state so that only good code is pulled out of the version control system for builds and code sharing. Another is to require individuals to create branches and merge when their code is ready to see the light of day. I would NEVER discourage anyone from checking in code, working or not, under the condition that the preferred method not break the overall process. --- Forwarded mail from [EMAIL PROTECTED] Thomas Tuft Muller wrote: Todd Denniston wrote: | I will however only give you the first line of such an | abomination that I have | been forced to live under: | cvs checkout -r HEAD -p $MODULE_NAME 2/dev/null $TMP_FILE2 | | It's up to you to determine what kind of tyrannical analysis of | $TMP_FILE2 you | want to do with a FORTRAN program or perl script. I fail to see why some(?) programmers are so reluctant to have their work analyzed and assessed. I'm a programmer myself, and I'm pretty sure that such a tool could benefit good programmers and maybe expose the bad seeds. Sound competion with fellow workers has never hurt anyone. I mean, a lot of employees out there have their work scrutinized and analyzed every day. Why should we be any different? Do we think we are irreplaceable no matter how much and what we actually do? Programmers constitute a very arcane society and I think a lot of companies would like to be able to assess the quality of the Software Development department as well as they do for other departments. The problem is that Software Quality is an understatement in a world where extreme programming emerges as the prevalent development process. I think (good) programmers should be the first in line for deploying tools and processes for assessing their own work. Or are we too scared? Only that we will be dealing with _another_ lazy boss who thinks just because the tool indicates it is bad that it is. These bosses are lazy because they do not want to spend the time to have the programmers understand each others code (peer review), and manage the fact that you will occasionally get a programmer who is a back biter. -- Thomas I wonder if anybody have som experience with using CVS to follow up work-quality, project progress, individual measurement of work amount done over specific periods of time etc, etc. I imagine a scenario where each programmer is forced to check in once a week (preferrably with a specific tag indicating that the files are possibly untested/uncompilable). hey, if the problem is small enough to solve in a week fine, however being forced to checkin code which may not be functional or may not be fully functional and then justify it, is only disruptive. Proper scripts could analyze the code regarding inter alia number of lines/words/bytes, Again only a manager who is lame brained (wait how many does than not describe) would still look at lines/words/bytes instead of functionality added or bugs squashed. commenting, commenting rules, coding-rules, Ok, this might make some sense, however peer review is better from the perspective of most rules have some point where they break down in the readability/maintainability of the code. class cohesion, method-length, class-length, parameter names, variable names, etc, etc. again, peer review still does this better and saner. In addition the scripts should also take into account the state of the archive last time the scripts were run, and analyze/provide statistics about the change. Unless your scripts can check all of the functionality of the system or show you which trouble reports were fixed, it is pretty useless. Better to check the commit comments and make the programmer put in something useful that can be tracked back to the requirements or trouble reports, so you can use something like http://www.red-bean.com/cvs2cl/ to generate your reports to your boss. Combined with a weekly/monthly submitted timeplan from the programmers, this could be a valuable tool for managers to see the overall as well as individual progress/quality. If your programmers are any good the things you mention above will not be valuable for measuring progress, you should be measuring system functionality and how well the programmers estimate time for adding functionality and fixing bugs. --- End of
RE: Comparing first; checking out later
You can also do cvs -n -q update, if you just want the list of files that will be touched (you won't see the actual changes) -Original Message- From: Matthew Riechers [mailto:[EMAIL PROTECTED]] Sent: Monday, June 4, 2001 9:55 AM Cc: [EMAIL PROTECTED] Subject: Re: Comparing first; checking out later Georgina O Economou wrote: I've searched thru all the documentation on CVS I could find, but cannot find this answer: How do I compare my local repository to the main one and see what differences there are BEFORE actually checking out the diffs and updating my local? Thanks Georgina cvs diff [files] http://www.cvshome.org/docs/manual/cvs_16.html#SEC129 Just to avoid confusion, don't refer to your working copy as the repository :) It sounds like you have the concepts a bit messed up. Check out http://cvsbook.red-bean.com/cvsbook.html for a really good treatment of CVS. -Matt ___ 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: Comparing first; checking out later
Georgina O Economou writes: How do I compare my local repository to the main one and see what differences there are BEFORE actually checking out the diffs and updating my local? I presume you mean, How do I compare my local *working directory* to the repository. There are a couple of ways: cvs -n update will show you what files have been updated in the repository (it will also show you what files you have modified locally). cvs diff -rHEAD will show you the differences between your files and the most recent version in the repository. (That assumes you're working on the trunk, which is the most common scenario. If you're working on a branch, just use the branch tag instead of HEAD.) -Larry Jones Everything's gotta have rules, rules, rules! -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs log
I need to create a report with the following information: symbolic names: revision: date: comment: I tried with cvs log but I can't filter the information for specific Tag. somebody have a query or script to generates a similar information. Any information I will appreciate. Moises ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS Login
Can someone tell me why CVS doesn't check my CVSROOT/password file for authentication. It just uses the system password. For instance, I have passwordX for system and PasswordY for CVS and when I try to login to CVS using passwordY, it rejects it, only accepting passwordX. Thank you __ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange error: EOF in value...
Dennis Jones writes: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Your repository has been corrupted -- the RCS file ends in the middle of what CVS thinks is the value associated with some keyword. The file may be truncated, or there could be come corruption in the middle that causes the quotes (which are actually @'s in RCS files) to get out of sync. Fixing it is tricky -- you pretty much have to manually edit the RCS file. You'll need an intimate knowledge of the RCS file format and either some way to get older revisions of the file or a willingness to lose them. You can probably locate the damaged section of the file by checking out different revisions, using a binary search along the revision tree to locate the damaged node. For example, if you can check out revision 1.1, then you know the trunk is OK and the damage must be on a branch. The most often reported cause of this type of damage is bugs in network filesystem code. If your repository is network mounted, I strongly suggest you stop that immediately and switch to a locally mounted repository on a server machine. -Larry Jones Let's pretend I already feel terrible about it, and that you don't need to rub it in any more. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange error: EOF in value...
No, it is mounted locally on a server...we are using pserver mode in a client/server environment. Thanks, I'll try checking out different revisions until I find an error. - Dennis - Original Message - From: Larry Jones [EMAIL PROTECTED] To: Dennis Jones [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 04, 2001 1:03 PM Subject: Re: Strange error: EOF in value... Dennis Jones writes: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Your repository has been corrupted -- the RCS file ends in the middle of what CVS thinks is the value associated with some keyword. The file may be truncated, or there could be come corruption in the middle that causes the quotes (which are actually @'s in RCS files) to get out of sync. Fixing it is tricky -- you pretty much have to manually edit the RCS file. You'll need an intimate knowledge of the RCS file format and either some way to get older revisions of the file or a willingness to lose them. You can probably locate the damaged section of the file by checking out different revisions, using a binary search along the revision tree to locate the damaged node. For example, if you can check out revision 1.1, then you know the trunk is OK and the damage must be on a branch. The most often reported cause of this type of damage is bugs in network filesystem code. If your repository is network mounted, I strongly suggest you stop that immediately and switch to a locally mounted repository on a server machine. -Larry Jones Let's pretend I already feel terrible about it, and that you don't need to rub it in any more. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Login
Bekaye Keita writes: Can someone tell me why CVS doesn't check my CVSROOT/password file for authentication. Well, it might be because the CVS-specific password file is CVSROOT/passwd, not CVSROOT/password. -Larry Jones I think we need to change the rules. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Problems adding files to cvs?
Hello there, I know this is a real noobie question but i've only recently started using cvs and i dont really know it too well. Anyway heres my problem. Whenever I try to add a file to the cvs tree i get the following error: RCS file: /test.java,v done cvs commit: Couldn't open rcs file `/test.java,v': Permission denied Checking in test.java; cvs commit: cannot open /test.java,v: Permission denied Segmentation fault (core dumped) For example purposes i used test.java as the file i wanted to check in. Everything else seems to work though( co , update, etc) so im not sure what it is? Any ideas thx _ Get your FREE download of MSN Explorer at http://explorer.msn.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange error: EOF in value...
Not in our caseour .dfm files are text (or, at least they are now). They were binary at one time, but were converted to text a long time ago. - Dennis - Original Message - From: Matthew Riechers [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 04, 2001 12:53 PM Subject: Re: Strange error: EOF in value... Dennis Jones wrote: I am getting the following message in a couple of files when checking out a branch. The main branch (top-of-trunk) checks out fine, but several other branches are having trouble. Apparently, people that already have the branch checked out are not seeing any errors, but doing a fresh checkout causes this error to occur: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Thanks, - Dennis Jones If the *.dfm format is not plain-text, you have to specify it as a binary file (cvs add -kb SelectVehicle.dfm) HTH, -Matt ___ 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: Strange error: EOF in value...
I'm attaching a script that will find the damaged version for you. donald On Mon, Jun 04, 2001 at 04:03:34PM -0400, Larry Jones wrote: Dennis Jones writes: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Your repository has been corrupted -- the RCS file ends in the middle of what CVS thinks is the value associated with some keyword. The file may be truncated, or there could be come corruption in the middle that causes the quotes (which are actually @'s in RCS files) to get out of sync. Fixing it is tricky -- you pretty much have to manually edit the RCS file. You'll need an intimate knowledge of the RCS file format and either some way to get older revisions of the file or a willingness to lose them. You can probably locate the damaged section of the file by checking out different revisions, using a binary search along the revision tree to locate the damaged node. For example, if you can check out revision 1.1, then you know the trunk is OK and the damage must be on a branch. The most often reported cause of this type of damage is bugs in network filesystem code. If your repository is network mounted, I strongly suggest you stop that immediately and switch to a locally mounted repository on a server machine. -Larry Jones Let's pretend I already feel terrible about it, and that you don't need to rub it in any more. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs check_cvs.pl
Versioning help after Tagging required.
Hi, I have been really struggling with CVS for a week now and hope that someone on this list can help me. Lets assume that I have a project with 2 file, 1.java and 2.java I created a repository and imported a module with these 2 files. Next, I check them out to a working directory. Lets say, I edit 1.java reach a milestone and commit (version 1.2) and then make some more changes and commit (v 1.3) All this while, 2.java is at v 1.1 Now I tag the whole module as say, release-1 and I'm happy. Now, I need to make changes to 2.java, but I want to start the versioning from 1.3, not from 1.1 ie, I want to bring my entire module to have a version 1.3, so that changes to any file from here on forth will be 1.4 (or 1.3.1.2 and so on...) How can I acheive this ? Been driving me nuts... BTW, I use wincvs with development on my hard disk only (for now). Thanks in advance, Sonya _ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Versioning help after Tagging required.
Sonya, I don't believe that it is possible to do what you are trying to do, but in any case, you shouldn't need to. What are you trying to accomplish? There is most likely a supported means to do the same thing. Chuck+ -Original Message- From: sonya31 [mailto:[EMAIL PROTECTED]] Sent: Monday, June 04, 2001 4:22 PM To: info-cvs Cc: sonya31 Subject: Versioning help after Tagging required. Hi, I have been really struggling with CVS for a week now and hope that someone on this list can help me. Lets assume that I have a project with 2 file, 1.java and 2.java I created a repository and imported a module with these 2 files. Next, I check them out to a working directory. Lets say, I edit 1.java reach a milestone and commit (version 1.2) and then make some more changes and commit (v 1.3) All this while, 2.java is at v 1.1 Now I tag the whole module as say, release-1 and I'm happy. Now, I need to make changes to 2.java, but I want to start the versioning from 1.3, not from 1.1 ie, I want to bring my entire module to have a version 1.3, so that changes to any file from here on forth will be 1.4 (or 1.3.1.2 and so on...) How can I acheive this ? Been driving me nuts... BTW, I use wincvs with development on my hard disk only (for now). Thanks in advance, Sonya _ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Versioning help after Tagging required.
Sonya Iyer [EMAIL PROTECTED] wrote: Now I tag the whole module as say, release-1 and I'm happy. Now, I need to make changes to 2.java, but I want to start the versioning from 1.3, not from 1.1 ie, I want to bring my entire module to have a version 1.3, so that changes to any file from here on forth will be 1.4 (or 1.3.1.2 and so on...) You might want to just ignore the RCS revision numbers (1.3, 1.3.2.1, etc.) -- just consider them to be an internal implementation detail of CVS -- and just use your tags to refer to the versions you want. But, if you really do want to set the RCS revision numbers, you can do so with 'cvs commit -r ...'. See http://cvshome.org/docs/manual/cvs_4.html#SEC47. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Strange error: EOF in value...
Thanks, I found the problem. We have been having some single-bit errors with our server (no, we still haven't replaced it!), and there was a 'c' character where a '@' should have been. When I corrected that, I was able to checkout the file, and it looks fine. After I fixed the probelm, I ran your script. It seems to have found lots more corrupt files in our repository. Ah, don't you just love computers? - Dennis - Original Message - From: Donald Sharp [EMAIL PROTECTED] To: Larry Jones [EMAIL PROTECTED] Cc: Dennis Jones [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 04, 2001 2:08 PM Subject: Re: Strange error: EOF in value... I'm attaching a script that will find the damaged version for you. donald On Mon, Jun 04, 2001 at 04:03:34PM -0400, Larry Jones wrote: Dennis Jones writes: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Your repository has been corrupted -- the RCS file ends in the middle of what CVS thinks is the value associated with some keyword. The file may be truncated, or there could be come corruption in the middle that causes the quotes (which are actually @'s in RCS files) to get out of sync. Fixing it is tricky -- you pretty much have to manually edit the RCS file. You'll need an intimate knowledge of the RCS file format and either some way to get older revisions of the file or a willingness to lose them. You can probably locate the damaged section of the file by checking out different revisions, using a binary search along the revision tree to locate the damaged node. For example, if you can check out revision 1.1, then you know the trunk is OK and the damage must be on a branch. The most often reported cause of this type of damage is bugs in network filesystem code. If your repository is network mounted, I strongly suggest you stop that immediately and switch to a locally mounted repository on a server machine. -Larry Jones Let's pretend I already feel terrible about it, and that you don't need to rub it in any more. -- Calvin ___ 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: Strange error: EOF in value...
On Mon, Jun 04, 2001 at 03:22:53PM -0700, Dennis Jones wrote: Thanks, I found the problem. We have been having some single-bit errors with our server (no, we still haven't replaced it!), and there was a 'c' character where a '@' should have been. When I corrected that, I was able to checkout the file, and it looks fine. After I fixed the probelm, I ran your script. It seems to have found lots more corrupt files in our repository. Ah, don't you just love computers? Well. It's better to have found and be able to fix it now *before* it becomes a serious problem ;) I'm glad you find the script usefull. donald - Dennis - Original Message - From: Donald Sharp [EMAIL PROTECTED] To: Larry Jones [EMAIL PROTECTED] Cc: Dennis Jones [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, June 04, 2001 2:08 PM Subject: Re: Strange error: EOF in value... I'm attaching a script that will find the damaged version for you. donald On Mon, Jun 04, 2001 at 04:03:34PM -0400, Larry Jones wrote: Dennis Jones writes: cvs [server aborted]: EOF in value in RCS file /vol/cvs/Projects/GenServr/SelectVehicle.dfm,v What is the meaning of this error, and what do I have to do in the repository file(s) to correct it? Your repository has been corrupted -- the RCS file ends in the middle of what CVS thinks is the value associated with some keyword. The file may be truncated, or there could be come corruption in the middle that causes the quotes (which are actually @'s in RCS files) to get out of sync. Fixing it is tricky -- you pretty much have to manually edit the RCS file. You'll need an intimate knowledge of the RCS file format and either some way to get older revisions of the file or a willingness to lose them. You can probably locate the damaged section of the file by checking out different revisions, using a binary search along the revision tree to locate the damaged node. For example, if you can check out revision 1.1, then you know the trunk is OK and the damage must be on a branch. The most often reported cause of this type of damage is bugs in network filesystem code. If your repository is network mounted, I strongly suggest you stop that immediately and switch to a locally mounted repository on a server machine. -Larry Jones Let's pretend I already feel terrible about it, and that you don't need to rub it in any more. -- Calvin ___ 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: Versioning help after Tagging required.
On Mon, Jun 04, 2001 at 05:07:56PM -0500, [EMAIL PROTECTED] wrote: Sonya Iyer [EMAIL PROTECTED] wrote: I want to bring my entire module to have a version 1.3, so that changes to any file from here on forth will be 1.4 (or 1.3.1.2 and so on...) You might want to just ignore the RCS revision numbers (1.3, 1.3.2.1, etc.) -- just consider them to be an internal implementation detail of CVS -- and just use your tags to refer to the versions you want. I'd word that more strongly. You REALLY SHOULD ignore the RCS revision numbers; cvs commit -r is a place you almost certainly don't want to go. For example, what happens when you add a new file, 3.java? It'll go in at revision 1.1 unless the person adding it remembers to give the right -r option for whatever module revision is appropriate at the moment. And they have to remember the -r at commit time, which may be quite a while after they cvs added the file. It's easy to forget to do this; thus, any process that depends on it is bound to be fragile. Use CVS tags instead; it's what they're for. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
edit -c
I am going to add "edit -c" into the cvs. I fail to make the cvs with the latest source of cvs. The error is make all-recursivemake[1]: Entering directory `/root/tmp/ccvs'Making all in libmake[2]: Entering directory `/root/tmp/ccvs/lib'Makefile:282: *** missing separator. Stop.make[2]: Leaving directory `/root/tmp/ccvs/lib'make[1]: *** [all-recursive] Error 1make[1]: Leaving directory `/root/tmp/ccvs'make: *** [all] Error 2 My Platform is Red Hat 7.0 under vmware. Attached is my config.status I work fine with cvs-1.11.1p1-cvshome.1.src.rpm. How may I contribute the edit-c patch? config.status
cvsignore problem
When I try to checkout (from WinCVS. Repository is on unix box.) I get this error: cvs server: cannot open /homeroot/.cvsignore: Permission denied Note 1: /homeroot is the actually home directory for the unix user root. Note 2: I am not root. I am cvsadmin and the entire software was installed as cvsadmin (except where root was needed). Questions: 1. Is the cvsignore file required? The documentation did not state that explicitly. 2. Where does it belong on unix and the pc? 3. Does it need to be on both? 4. Why is it going to the /etc/passwd file and using root's home directory as a starting point? Initially, I had this problem on the unix side as well. But I added a passwd, readers and writers files to CVSROOT. I have no problems as any user on the unix box now where as I was getting this problem on both unix and windows before. Is it something particular to the windows side? I have been fighting this all day and am making no progress. Please help! Jeanie ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and assesment
On Mon, Jun 04, 2001 at 04:44:34PM +0100, Thomas Tuft Muller wrote: I fail to see why some(?) programmers are so reluctant to have their work analyzed and assessed. Because (usually) we *can* resist it. Peons doing data entry have been subject to keystroke monitoring and such dehumanizing management techniques for years, but (unless they're unionized) have had no recourse. Programmers are in a better bargaining position (or have been until the last few months). Besides repugnance on general principles, my concerns would be, in no particular order: - Do the metrics measure quality of work, or merely quantity? In other words, will I be penalized for the time and effort it takes to come up with a *good* design, implement it with *good* code, test thoroughly, and write *good* documentation, instead of just blasting out any old junk to keep my lines/week up to snuff? - As someone else mentioned, whatever the standard (naming schemes, comments, formatting, etc.), it occasionally makes more sense to violate it. Such a mechanical scheme will flag people for this. Will management be receptive to peoples' arguments, on a case-by-case basis, as to why it seemed wiser to break a given rule; or will they simply say follow the rules, dammit even when that leads to inferior results? I'm a programmer myself, and I'm pretty sure that such a tool could benefit good programmers and maybe expose the bad seeds. Good as defined by the metrics used. I've usually been able to recognize bad seeds in the teams I've been a member of. If management can't, tools like this won't help them. This is like IQ, which just keeps getting more discredited as a measure of intelligence (whatever that is) as the years go by. Sound competion with fellow workers has never hurt anyone. Since when is a climate of fear conducive to morale, or to productivity -- especially in a task as creative as programming? I mean, a lot of employees out there have their work scrutinized and analyzed every day. Why should we be any different? Why should we *not* be, if we have the clout to demand better treatment? Do we think we are irreplaceable no matter how much and what we actually do? Of course not. Neither are the managers, no matter how awful they are. When someone comes up with a metric that can fix *that* problem, and agrees to abide by its results, I'll be more willing to accept the metric he wants to apply to his subordinates, ie. me. Programmers constitute a very arcane society and I think a lot of companies would like to be able to assess the quality of the Software Development department as well as they do for other departments. A real problem. I'm not sure what the solution is, but I don't think this is it. I think (good) programmers should be the first in line for deploying tools and processes for assessing their own work. Or are we too scared? Yes, I'm scared of this stuff. I'm afraid of being made to look bad, compared to people who really *are* bad programmers (or mediocre at best), by metrics that can't measure quality. And I'm afraid of pointy-haired managers who'll take the latest fad in programming metrics as gospel, and use them as a cheap and easy substitute for doing their own jobs properly. /rant -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvsignore problem
Check the documentation: http://faq.cvshome.org/fom-server/cache/23.html donald On Mon, Jun 04, 2001 at 06:00:32PM -0700, Schwenk, Jeanie wrote: When I try to checkout (from WinCVS. Repository is on unix box.) I get this error: cvs server: cannot open /homeroot/.cvsignore: Permission denied Note 1: /homeroot is the actually home directory for the unix user root. Note 2: I am not root. I am cvsadmin and the entire software was installed as cvsadmin (except where root was needed). Questions: 1. Is the cvsignore file required? The documentation did not state that explicitly. 2. Where does it belong on unix and the pc? 3. Does it need to be on both? 4. Why is it going to the /etc/passwd file and using root's home directory as a starting point? Initially, I had this problem on the unix side as well. But I added a passwd, readers and writers files to CVSROOT. I have no problems as any user on the unix box now where as I was getting this problem on both unix and windows before. Is it something particular to the windows side? I have been fighting this all day and am making no progress. Please help! Jeanie ___ 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: Running editor while `cvs commit' not on terminal
Alexey Mahotkin writes: man isatty Exactly. CVS runs on a lot of systems that don't have a man command, let alone an isatty() library routine. And, surprisingly enough, some people *do* use non-interactive editors (typically scripts of some sort that generate the log message without user interaction). -Larry Jones We seem to be out of gun powder. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Broken log message in fresh CVS
Alexey Mahotkin writes: why ever does fresh CVS add an empty line in the beginning of log message no more :( Why should it? There doesn't seem to have even been a good reason for the blank line and people with carefully crafted rscinfo templates for their log messages were understandably upset by it. It's very annoying to constantly monitor yourself when typing appropriate letter in vi when using fresh CVS at home and older one at work... I don't understand what you mean, could you explain the problem you are having in more detail? -Larry Jones It seems like once people grow up, they have no idea what's cool. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .#files left after `cvs init'
Alexey Mahotkin writes: When creating repositories with `cvs init' there are lots of backup files left with names like '.#modules'. Is this a bug or a feature? Feature -- that's the naming convention that CVS uses for backup files. For example, if updating a file causes a merge, the original pre-merged file is kept in .#file.rev. -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
'cvs update -C' and loginfo
'cvs update -C' works differently when called inside loginfo. Maybe some kind soul can point me at why this is so. Our site makes use of the auto-update mechanism for part of our website as described in the Cederqvist et al manual [http://www.cvshome.org/docs/manual/cvs_18.html#SEC163]. Our problem is that files get checked in w/o their being based on the immediate ancestor so often there are merge conflicts. Since the auto-exported directory is sitting under a webserver, having files w/ merge conflicts in them is undesirable. I thought I could just add a '-C' to the 'cvs update -d' in our loginfo. The '-C' seemed to work as desired when tried on the command line, but its behavior is otherwise when called inside loginfo. Here is what I see when I do a 'cvs update -d' (The repository is via pserver): [stack@sc-test3 master]$ cvs update -C Footer.wm (Locally modified Footer.wm moved to .#Footer.wm.1.24) U Footer.wm Here is what I see after adding the '-C' flag to loginfo: ... Checking in Footer.wm; /usr/local/tigris/data/helm/cvs/repository/look/www/master/Footer.wm,v -- Footer.wm new revision: 1.25; previous revision: 1.24 done 1 file(s) commited Processing log script arguments... Mailing the commit message to [EMAIL PROTECTED] (from [EMAIL PROTECTED]) cvs update: Updating . ... cvs update: Updating master RCS file: /cvs/look/www/master/Footer.wm,v retrieving revision 1.24 retrieving revision 1.25 Merging differences between 1.24 and 1.25 into Footer.wm rcsmerge: warning: conflicts during merge cvs update: conflicts found in master/Footer.wm C master/Footer.wm ... Why is it applying a patch when I explicitly want it to ignore what is on disk and just pull from the repository? Thanks for any pointers. St.Ack ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Running editor while `cvs commit' not on terminal
There was a conversation sometime about changing the default behaviour to something other than 'continue'. That would be an improvement in this situation. At 14:14 04/06/01 -0400, Donald Sharp wrote: The '' symbol tells the users shell to do something with the output. cvs can do nothing( it doesn't know where it's stdout and stderr are going ) when the user does this. donald On Sun, Jun 03, 2001 at 08:41:05PM +0400, Alexey Mahotkin wrote: I've seen several times report on the following misfeature: sometimes one inadvertantly runs $ cvs commit results 2errors After that things depend upon user's editor. In one case (vi not checking if on terminal) the user had to blindly type ESC:q! and things seemed to be ok. I checked that with VIM and got the following: === errors === cvs commit: Examining . ex/vi: Vi's standard input and output must be a terminal cvs commit: warning: editor session failed === /errors === === stdout === Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) Checking in hello.c; /repos//testing/hello.c,v -- hello.c new revision: 1.3; previous revision: 1.2 done === /stdout === I think that it is rare but very annoying case that should be fixed. --alexm ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Running editor while `cvs commit' not on terminal
The '' symbol tells the users shell to do something with the output. cvs can do nothing( it doesn't know where it's stdout and stderr are going ) when the user does this. donald On Sun, Jun 03, 2001 at 08:41:05PM +0400, Alexey Mahotkin wrote: I've seen several times report on the following misfeature: sometimes one inadvertantly runs $ cvs commit results 2errors After that things depend upon user's editor. In one case (vi not checking if on terminal) the user had to blindly type ESC:q! and things seemed to be ok. I checked that with VIM and got the following: === errors === cvs commit: Examining . ex/vi: Vi's standard input and output must be a terminal cvs commit: warning: editor session failed === /errors === === stdout === Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) Checking in hello.c; /repos//testing/hello.c,v -- hello.c new revision: 1.3; previous revision: 1.2 done === /stdout === I think that it is rare but very annoying case that should be fixed. --alexm ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Broken log message in fresh CVS
Alexey Mahotkin writes: When I'm working at work (on older CVS) I have to type i in vi to go into insert mode. At home (on newer CVS) I have to type O in vi to insert new blank line and go into insert mode. Am I clear? :) Just always type O -- CVS deletes trailing blank lines from the message. But it doesn't delete leading blank lines, and that's where the old blank line was if you did have an rcsinfo template. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Running editor while `cvs commit' not on terminal
I've seen several times report on the following misfeature: sometimes one inadvertantly runs $ cvs commit results 2errors After that things depend upon user's editor. In one case (vi not checking if on terminal) the user had to blindly type ESC:q! and things seemed to be ok. I checked that with VIM and got the following: === errors === cvs commit: Examining . ex/vi: Vi's standard input and output must be a terminal cvs commit: warning: editor session failed === /errors === === stdout === Log message unchanged or not specified a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining dirs Action: (continue) Checking in hello.c; /repos//testing/hello.c,v -- hello.c new revision: 1.3; previous revision: 1.2 done === /stdout === I think that it is rare but very annoying case that should be fixed. --alexm ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Broken log message in fresh CVS
LJ == Larry Jones [EMAIL PROTECTED] writes: why ever does fresh CVS add an empty line in the beginning of log message no more :( LJ Why should it? There doesn't seem to have even been a good reason LJ for the blank line and people with carefully crafted rscinfo LJ templates for their log messages were understandably upset by it. Hm. I do not have any rcsinfo template. Or have I? :) It's very annoying to constantly monitor yourself when typing appropriate letter in vi when using fresh CVS at home and older one at work... LJ I don't understand what you mean, could you explain the problem LJ you are having in more detail? When I'm working at work (on older CVS) I have to type i in vi to go into insert mode. At home (on newer CVS) I have to type O in vi to insert new blank line and go into insert mode. Am I clear? :) And I do not have any rcsinfo template in a sense that I've never touched the default one that was installed with 'cvs init'. --alexm ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Running editor while `cvs commit' not on terminal
DS == Donald Sharp [EMAIL PROTECTED] writes: DS The '' symbol tells the users shell to do something with the DS output. cvs can do nothing( it doesn't know where it's stdout and DS stderr are going ) when the user does this. man isatty :) --alexm ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs rtag -r BRANCH -D date
If I try to say $ cvs rtag -r BRANCH -D 23 Jan 2001 TEST junk it says cvs [rtag aborted]: -r and -D options are mutually exclusive The thing is that those options are mutually exclusive only when -r specifies non-branch tag. If there is no other method of tagging branch by date, this should be made one. $ cvs rtag -r BRANCH TEST junk works like a charm. Probably it's not so hard to extend its functionality... Thank you, --alexm ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
