Re: CVS Export
Liquidchild writes: When i run the cvs export command either through WinCVS or on the command line using [...] it exports the ecc module with the CVSROOT folders and CVS folders. Have you looked at the repository to see if someone managed to actually add those directories to it? -Larry Jones I've got to start listening to those quiet, nagging doubts. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Locking CVS
Jim Hyslop writes: If you want to lock all projects, then create an empty $CVSROOT/CVSROOT/writers file. I believe this will work for all access methods, not just pserver. You believe incorrectlly. The readers and writers files only affect pserver. -Larry Jones You should see me when I lose in real life! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Error while checking out.
Sumit Dey writes: cvs [server aborted]: cannot write D:/CVSRepo/Project342/CVSROOT/val-tags: Permission denied Any help will be greatly appreciated. I don't see how the error message could be any clearer -- you need to change the permissions on your val-tags file so that anyone can write to it. See the manual: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones Even my FRIENDS don't do what I want. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How do I get a barebone stripped off list of files changed between
S I writes: I'm trying to get a stripped down list of files modified and committed between 2 builds or a build and my working folder in CVS. I would just like to see the path/filename only. Compare it to a list received from the developers to verify we're in synch, do the build and deliver their corresponding .class files. Take a look at rdiff -s. -Larry Jones Fortunately, that was our plan from the start. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Annotate of Log output wrong
Ming Kin Lai writes: The original discussion appeared to focus on the expansion of the $Log$ keyword both in the file and as output by the cvs annotate command (under version 1.11.17); but I think other keywords such as $Id$ have the same problem. They do. The bottom line is that keywords are expanded to their current values by the checkout/update process that is also part of the checkin process and some other processes (like diff). Annotate, on the other hand, annotates the RCS file as-is, without any further processing. Feel free to submit patches if you would like it to behave differently. -Larry Jones They can make me do it, but they can't make me do it with dignity. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: pserver user id's
foomonkey writes: If I change the passwd file to look like this: divap:YBGW948yOKKSA:divap Note that you can just omit the third field entirely in that case. I get an error when I try to run a 'checkout' on a project in the divap directory that says: cvs [checkout aborted]: unrecognized auth response from cae1axp1: setgroups: Not owner Your [x]inetd must run cvs as root to be able to switch to another user. -Larry Jones I'm not a vegetarian! I'm a dessertarian. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: pserver user id's
foomonkey writes: I may be missing something but that's the way things appear to me. Is there any danger in having pserver run as root? inetd.conf contains many other services running as root. I realize that ANY service running as root or otherwise introduces certain vulnerabilities. You've got it. Pserver runs as root just long enough to authenticate the user and then it switches to the actual user to run everything else so there's very little risk. -Larry Jones The game's called on account of sudden death. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Read-Only Access: readers writers files
S I writes: Posting a 2nd time; Have patience, grasshopper. I find the documentation for readers and writers files somewhat confusing and ambiguous. Could both readers and writers coexist or one at any given time? Yes, although it doesn't make much sense. The next to last paragraph makes it clear that the writers file trumps the readers file. (In other words, if the writers file exists, then users listed in it get write access and everyone else gets read-only access, regardless of the contents of the readers file.) Question 1: Could anyone tell me when (as of what version) these files were implemented? I'm running CVS 1.11.1p1 on our Linux server and I just created the 'readers' file anyway and added a user to and will ask him to test it. I don't think I could or would want to test and block myself lest running the risk of undoing what I've done. Would my current version of CVS understand readers? As far as I can recall, they've been there as long as pserver mode has. Certainly they're supported in 1.11.1p1 (but there are lots of bugs that have been fixed since then, so you really should update). Question 2: If not, then I'm overdue an upgrade and hate to bring down the server during a critical release. Would someone please shed some light on upgrading? First, read the NEWS file for the new version to see if there have been any changes that are going to affect you. Usually there aren't and all you have to do is replace your current CVS executable with the new one. You should run ``cvs init'' afterwards to perform any necessary updates to your repository (but there haven't been any necessary updates -- the most it will do is create any new administrative files -- so you don't *have* to do it, but it's still a good idea). -Larry Jones They say winning isn't everything, and I've decided to take their word for it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs
Ryan Meder writes: Dont know if you can help but would be great if you can, my cvs on mandrake is running but i am unable to set the required permission to access it from eclipse. Please read the section of the manual on permissions: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 If that doesn't help, please provide more details about what's going wrong (exact error messages, what user you're trying to run as, what the ownership and permissions are on the repository directories, etc.). -Larry Jones I always send Grandma a thank-you note right away. ...Ever since she sent me that empty box with the sarcastic note saying she was just checking to see if the Postal Service was still working. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Cannot remove directories from the CVS repository
Peter Desjardins writes: cvs checkout: cannot remove directory/subdirectory: Directory not empty Did you say what platform you're on? Can you remove the directories by hand, or do you get the same error? It sounds to me like some weird permissions problem. -Larry Jones When you're SERIOUS about having fun, it's not much fun at all! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can you use pserver with multiple repositories?
foomonkey writes: But... I wanted to create subrepositories like /cvs/mq, /cvs/java, etc. Why do you want to create multiple repositories rather than just having multiple modules/directories in a single repository? Is this because the entry in inetd.conf specifies --allow-root=/cvs ? In other words, pserver only knows about the one repository which exists in /cvs. It doesn't look for the one I specify on the command line on the remote computer. Correct -- the repository you specify must exactly match one of the --allow-root= options for the server. (Note the one of in the previous sentence -- you're allowed to have multiple --allow-root= options.) -Larry Jones Wow, how existential can you get? -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Can you use pserver with multiple repositories?
Andy Pierce writes: The idea is that different development teams would have their own repositories in which they could place their projects. We're a large company and it would be nice to have them segregated. So just add a level of directories: have one top-level directory for each team to put their projects in. Multiple repositories on the same machine really only makes sense if you're going to have multiple administrators and need multiple sets of admin files or if you think you may need to split them out to different machines in the future (in which case you should give them different server names now and just map them all to the same IP address). So does this mean I specify multiple --allow-root's on a single 'cvspserver ...' line Yes, but please note the caveats in the manual about inetd argument limits: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC30 -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Don't commit during tagging
Russ Sherk writes: CVS also locks on checkin/tagging (at least rtag locks). I am not sure as to wheather it locks on a per file basis or for the entire duration of the tag process tho. CVS never locks individual files -- only directories. In the case of tag and rtag, CVS locks each directory in turn while its files are tagged. It does not lock the entire tree for the duration of the tag operation. -Larry Jones ...That would be pretty cool, if they weren't out to kill me. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: error in installable file
ravish agarwal writes: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary1808497700== Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! *gunzip: cvs-1.11.20-HP.gz: not in gzip format* Like it says in README.binaries: If you get errors during decompression, it may well be that your browser decompressed the file during download but neglected to remove the .gz or .bz2 from the file name -- try renaming the file to cvs and changing the permissions (if necessary) to make it executable. -Larry Jones Another casualty of applied metaphysics. -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS log between revs - filter extra info
Russ Sherk writes: I have been trying to get a cvs log between revs that only shows log messages for what has changed between revs. I've tried cvs log -rrev1:rev2 and -rrev1::rev2. Both of which either show way too much info or not enough. Where extra data is logs for files that have not changed. And not enough data means that some files are excluded (because of the nature of : and ::). cvs log -S -rrev1::rev2 should do exactly what you want, provided you're using a reasonably recent release of CVS. If not, please be specific about what's wrong, preferably with actual examples. -Larry Jones Things are never quite as scary when you've got a best friend. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: problem
Priit Serk writes: This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! cvs diff -r ver2 gives an error: cvs [diff abortd]: read lock failed - giving up also same error occures with checkout (read lock failed) I'm new to cvs and at this moment i dont know what I will have to do. Tell us what release of CVS you're using and show us the complete output you get -- you should never get that message without another message that further explains the problem (unless, perhaps, you're using CVSNT rather than regular CVS, in which case you're asking in the wrong place). -Larry Jones Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: FreeBSD
[EMAIL PROTECTED] writes: Is there a version of CVS that runs on FreeBSD? I only see versions for other Unix platforms, just nothing that explicitly says FreeBSD. Can anyone help? Just build it from the source -- it works fine. -Larry Jones Oh, what the heck. I'll do it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Modifying the comment
S I writes: How's is it possible to remodify the comment w/o checking in and out the file again, if you inadvertently checked it in with the wrong comment? cvs admin -m -Larry Jones In a minute, you and I are going to settle this out of doors. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I just instigated admin controls by opening up and configuring the UserAdminOptions setting. My account is a member of Linux cvsadmin group, yet like non-privileged users I cannot execute admin commands. Then you're not really a member of the cvsadmin group. If you just added your account to the group, you have to log out and back in again before it takes effect. The id command will show you which groups you're really a member of. -Larry Jones Girls are so weird. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: That's the confusing thing; id tells me I'm a member of cvsadmin. Is there any restriction about userid range? I'm 1000, cvsadmin group is 502. In that case, my guess is that you're not using your account, you're using the generic cvs account (you say all of your CVS users are mapped to the same cvs system user and it's the system user that has to be in the cvsadmin group). Mapping all of your CVS users to the same system user destroys any system-level security or accountability since everyone appears to be the same user. If you have SSH access to the system, you're much better off using it directly in :ext: mode as individual system users rather than tunnelling pserver and mapping everyone to the same user. -Larry Jones When you're as far ahead of the class as I am, it doesn't take much time. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I'm not quite sure what you mean by mapping users. Using the third field of the CVSROOT/passwd file to have the server run as some user other than the actual user. I want each user to have his own login to the system, and I want to control access to CVS repositories on a per-user basis, which is why I use pserver. There's no need to use pserver for that. In fact, pserver is a giant security hole that is best avoided. Since you're giving your users ssh access to the server anyway, the best thing for you to do is to use :ext: mode with ssh rather than rsh (which should be the default if you're running CVS 1.12). Each user logs in as themselves and you can then use ordinary file permissions to control who has access to what. See the manual for details: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_2.html#SEC13 -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problem with admin privileges
Julian Opificius writes: I have one more issue that affects my choice that I should have mentioned earlier. We are working in an FAA-regulated environment, and my CVS respository must be secure, in that nobody can impair the lifecycle data, and all accesses must be documented and controlled, i.e.e all accesses must be via the cvs server. This is why I chose pserver in the first place. Please note that CVS was designed to enable collaboration, not to enforce access controls and audit trails. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: a newbie facing tagging problem
[EMAIL PROTECTED] writes: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! When we tag main directory of a project it is shown that For xyz/abcsys/src/base/vlan/Makefile HEAD and other tags are shown correctly. Branch:MAIN inside vlan directory there is another vlan sub directory. But for files in this: For xyz/abcsys/src/base/vlan/vlan/Makefile Only HEAD tag is shown. Branch:MAIN Due this I am facing tremendeous problem in building old versions. What could be the cause/solution for the problem. The problem is that the files in that directory have never been tagged. From you description, it's not clear whether you're trying to apply a new tag or you're trying to use a tag that was applied some time in the past. If the problem is with a new tag that you applied using cvs tag, it would appear that your working directory has become corrupted in some way such that CVS commands don't know that that directory exists. If there aren't any changes in your working directory that you need, the simplest fix is to delete it and do a new checkout. Otherwise, check the CVS/Entries file in the parent vlan directory -- it should contain an entry for the vlan subdirectory, which you can add by hand if necessary. If the problem is with an old tag, the problem is that the directory was never tagged in the first place and there's nothing you can do now to fix it other than trying to recreate the correct state of the directory (perhaps by updating to a particular date/time) and applying the tag now. -Larry Jones It's going to be a long year. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Lock Files
S I writes: Thank you. But do you see anything wrong with me manually removing such files? They won't corrupt CVS or anything like that, would they? Yes, it very well might. You're not making any attempt to differentiate between legitimate lock files (caused by someone currently running CVS) and stale lock files (those left over from something horrible happening). Removing legitimate lock files is a recipe for disaster. Figuring out which is which is somewhat tricky, particularly in a script, so I strongly suggest you figure out what the horrible thing is that's happening to leave you with stale lock files and fix it. -Larry Jones Just when I thought this junk was beginning to make sense. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Using log to list files of a tag
Aaron Jackson writes: I'm trying to use rlog to get the history of a group of files included in one tag. I want to be able to see all of the other tags that this file is assigned to as well. Using the output below as an example, lets say I'm looking for a_project_2 in the log. The output should be as below with all files belonging to the tag a_project_2. Right now when I run the log I get all files including those that do not belong to a_project_2. I've been browsing the man pages and the syntax I understood was as in the command below. command: cvs log -ra_project_2 a.project -r only specifies what revision messages to print, it does not affect what headers are printed. You need to add the -S flag to suppress the headers of files with no revisions selected. -Larry Jones Your bangs do a good job of covering up the lobotomy stitches. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: HEAD versus Trunk
Rod Macpherson writes: Why doesn't CVS treat HEAD like a branch tag where the branch is the main branch, that is to say the trunk. Why aren't rocks soft like pillows? I cannot commit files checked out as HEAD. Treats it like a garden variety version label versus trunk. That's because it *is* a garden variety version label. The tip of the trunk is what you get when you don't specify *any* revision or date. Use update -A to get rid of the sticky HEAD version tag and you'll be able to commit. -Larry Jones Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check out fails
Todd Denniston writes: If you are using pserver you should not need to su, [x]inetd runs as root. But is it set up to run pserver as root? If not, you can only run as the user you're running pserver as -- any attempt to run as a different user will result in similar problems (although one would expect initgroups() to fail with EPERM rather than EINVAL). -Larry Jones You can never really enjoy Sundays because in the back of your mind you know you have to go to school the next day. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check out fails
Rancier, Jeff writes: This aside, it was the cvsd on the Windows box (the repository) which was reporting the initgroups error then? I mean, why would the local cvs client care, right? I'm confused -- I thought the repository was on the Solaris box?!? Perhaps you need to start over -- tell us exactly what your configuration is: what version(s) of CVS you have on which boxes, which box is the client and which is the server, how you're running the server (inetd, xinetd, etc.), the relevant entry from the inetd/xinetd/whatever config file, the relevant entry from the CVSROOT/passwd file, the exact cvs commands you type and the exact results. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check out fails
Todd Denniston writes: which would imply either the user name given was invalid (for where initgroups looked) or the additional group was. Does initgroups get pointed at CVSROOT/passwd if it exists? No, it just gets the username and associated gid from the system passwd file. If the username were invalid, the passwd file lookup would have failed, so that's not it. If the associated gid were invalid, the user probably wouldn't be able to log in, so that's probably not it either. I do note that getgroups() can fail with EINVAL if there are more groups than will fit in the output argument. Perhaps there's an undocumented internal limit in initgroups() that he's running into -- how many groups is that user in? -Larry Jones I hate it when they look at me that way. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: HEAD versus Trunk
Rod Macpherson writes [using very long lines]: To paraphrase your answer: because. None of us where there when the decision was made, so you can't expect a definitive answer. :-) But I suspect that HEAD was created because a floating revision tag that references the tip of the trunk is handy in certain circumstances. There probably didn't seem to be any need for a branch tag for the trunk (though if there were, TRUNK would be a better choice than HEAD) since that's what you get by default. I think it's kind of a moot question at this point so I will retract it. HEAD is what it is. Changing it to be the name of trunk would break scripts from here to eternity. Exactly. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check out fails
Rancier, Jeff writes: One key thing I think I ommitted, is that xinetd/cvs on Windows are Cygwin's. The bigger thing you omitted is that you're using Windows *at all*. Your original question only mentioned Solaris! Again, you need to take a step back and tell us about your environment -- what machines you have and what you intend to use them for. Unix is a much better place to host a repository than Windows. If you insist on hosting on Windows, you're better off using CVSNT than regular CVS running under cygwin (since that way you only have to deal with Windows rather than having to deal with both Windows and cygwin). -Larry Jones The game's called on account of sudden death. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Exporting a subdirectory only...
Ken Keefe writes: I have a cvs module that has two subdirectories, images and web. I'd like to export only the contents of the web folder into ./webserver/. Is there a way I can do that with a simple CVS command? cvs export -r whatever -d webserver mymod/web -Larry Jones You should see me when I lose in real life! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Removing Without Committing
Rod Macpherson writes: Remove says it schedules removal so does that mean the repository still thinks there is a pending removal? Adding and removing only affect your sandbox, they don't affect the repository at all until you commit them. -Larry Jones Fortunately, that was our plan from the start. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Info-cvs Digest, Vol 31, Issue 10
Santosh_Nandagiri writes: Is there any way that the user is notified every time he performs a Commit to perform an Update before doing that. That's not necessary -- if any of the files being committed are not up to date, CVS will refuse to do the commit until after the user updates. -Larry Jones Even though we're both talking english, we're not speaking the same language. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: loginfo on CVSNT
yinhua writes:
This is a multi-part message in MIME format.
Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!
For the filename, version numbers I can use %{sVv} to get easily, but for
the log message, is there any way to get this information?
It's sent to the script's standard input stream. See the manual for
details:
https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC175
-Larry Jones
How many presents do you think I'd forfeit for just one
clean smack upside Susie's head? -- Calvin
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: I have encounter a problem in CVS setup
Qian Xin writes: Yes, updating to a new version of cvs may fix it. I will try this method. But I want to know why? Updating *will* fix it -- only ancient versions of CVS have this problem. https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_21.html#SEC189 -Larry Jones I sure wish I could get my hands on some REAL dynamite. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs checkout date
[EMAIL PROTECTED] writes: I would like my application to print, when executed, the date when the source from which it was built was retrieved from the cvs tree. See the manual: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_12.html#SEC97 -Larry Jones If I get a bad grade, it'll be YOUR fault for not doing the work for me! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: have finished reading http://cvsbook.red-bean.com/cvsbook.html
Stuart Cooper writes: but this is a bit tricky, so making copies, doing cvs update -A and then moving the copies over and then checking in is perfectly acceptable. As long as you're the only one making changes. If there's a possibility of other people checking in changes, too, you need to check after the update -A for other changes that need to be merged into your changes. In that case, doing the update correctly (with two -j options) is much simpler. -Larry Jones I don't like these stories with morals. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Restore an old version and save it as the new one
Fritz Bayer writes: I have reached version 1.6 and I would like to restore version 1.3 for all files and store those under version 1.7. See the manual: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_5.html#SEC62 -Larry Jones All girls should be shipped to Pluto--that's what I say. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: have finished reading http://cvsbook.red-bean.com/cvsbook.html
Sergei Organov writes: How is it different from update -A *without* copying anything on top of it? My experience is that update -A would perform regular merge of current changes into the head version. Am I missing something? You're missing the fact that copying an old file over top of the current file will wipe out any subsequent changes that were merged into the current file by the update. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: On the Utility of Update -A
Rod Macpherson writes: This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! What purpose does the update -A switch serve other than to switch you back to the HEAD of trunk after creating a branch? It also reverts any local -k options back to the repository defaults. With the exception of that narrow use case it seems to be dangerous and confusing. It also seems to be redundant as there is a more general way of switching branches and merging changes from the top of a branch. Not suggesting that's all true but that's the impression I have and would appreciate some clarification. I don't see what's dangerous or confusing about it, it's a quick way to throw away any local configuration and get back to a normal working directory. What's perhaps confusing or dangerous is people screwing around with local configuration when they don't know what they're doing. -Larry Jones Mom would be a lot more fun if she was a little more gullible. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: I have encounter a problem in CVS setup
[EMAIL PROTECTED] writes: But I always encounter the error report: cannot open /root/.cvsignore: Update to a reasonably recent version of CVS (from www.cvshome.org). -Larry Jones Oh, now YOU'RE going to start in on me TOO, huh? -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: do I need to checkout directory tree to compile it ?
Aaron Gray writes: Do I need to checkout a projects whole directory tree in order to compile it or is there another command that will give me a copy of the tree without checking it out ? You can export it instead, but there's really nothing wrong with checking it out. -Larry Jones He doesn't complain, but his self-righteousness sure gets on my nerves. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: List of files changed between 2 tags
[EMAIL PROTECTED] writes: I was doing a 'cvs diff -s -r -r ' but I thought that there must be something else out there, but I just was not aware of it. Have you looked at cvs patch -s? -Larry Jones I don't want to be THIS good! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: intermittent cvs lock messages
Sam Steingold writes:
I use loginfo to e-mail the commit information to a mailing list:
ALL /cvsroot/sitedocs/CVSROOT/cvstools/syncmail -u -f users.sourceforge.net
%{sVv} [EMAIL PROTECTED]
syncmail source code:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/cvs-syncmail/syncmail/syncmail
That's your problem. syncmail uses CVS commands to generate a diff to
include in the mail -- if it tries to do that before your commit
finishes, it will block waiting for your commit's lock. I would suggest
changing syncmail to use cvs -n for the diff, which will ignore the
lock.
-Larry Jones
When you're as far ahead of the class as I am, it doesn't take much time.
-- Calvin
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to undo a commit?
Christian Hujer writes: What is the best way to make the HEAD revision of the files being the previous revision? You want to do a reverse merge to undo the changes and then commit. To do that, you'll need to (temporarily) tag the version you want -- I suggest updating your directory (probably using a date/time) to the state you want. Once you've verified that it is, in fact, what you want, tag it and do the reverse merge. The sequence would be something like: cvs update -D yesterday cvs tag TEMP cvs update -j HEAD -j TEMP cvs commit -m'undo erroneous checkin' cvs tag -d TEMP Note that if there is any possibility of anyone else having checked in changes after your erroneous checkin, you should tag the files (with a second temporary tag) before updating to the previous state and then use that tag instead of HEAD in the merge to avoid undoing those other changes. -Larry Jones They say winning isn't everything, and I've decided to take their word for it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Questions on pserver authentication
Todd Foster writes: I am trying to determine how pserver authentication works. I understand when you do a cvs login that it creates ~/.cvspass file. Therefore, I'm guessing that whenever you are running cvs commands cvs blindly combines the USER from whichever method wins (either using the pserver info found in the local working copy or in the $CVSROOT or in the -d) and uses the password from the ~/.cvspass of whoever is running the commands. Is this correct? Almost. The .cvspass file records the entire CVSROOT specification (not just the user name) and the corresponding password. So, when you run a cvs command, it looks up the actual CVSROOT (whether from the working directory, the environment, or the command line) in .cvspass and uses the corresponding password (or an empty string if no corresponding password exists). So, if user1 goes into a cvs directory created by user2 and tries to do cvs commands in there, it uses the username found in the local working copy (user2) and combines that with ~user1/.cvspass and authentication fails. Not necessarily, user1 could have logged in using user2's CVSROOT setting (or copied the entry from user2's .cvspass file). But it's a very bad idea to share working directories -- the whole point of CVS is to allow concurrent changes in a controlled fashion and you can very well be making concurrent changes if you're sharing the working directory. What I'm really wondering, is what does the pserver authentication do if the username is omitted from the pserver CVSROOT, then what happens? Since it can't determine username from the CVSROOT, does it use the USER who is running the command? Yes. In that scenario, if user1 goes into user2's directory and does a cvs command, since it can't find the username in the pserver information, would it combine user1 with ~user1/.cvspass and work just fine? It depends on whether the CVSROOT that's recorded in that working directory (in CVS/Root) has a user name in it or not. -Larry Jones Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Commitinfo - finding files on the server
[EMAIL PROTECTED] writes: According to information I've read on the web, when a commit is made on a local machine to a remote server, exact copies (i.e. non-RCS format) of the files being committed are created temporarily on the server so that they are available for commitinfo scripts to act on them. I need to write a commitinfo script that will parse committed files to make sure they have appropriate copyright statements. To run that script on the server, I'll need to get access to those non-RCS format files. However, I'm having trouble locating where those files are on the server They're in the script's current working directory. -Larry Jones Years from now when I'm successful and happy, ...and he's in prison... I hope I'm not too mature to gloat. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Retrospectively creating a branch - howto?
Simon Brooke writes: -[simon]- cvs co -D2005-04-10 jacquard -[simon]- cd jacquard -[simon]- cvs tag -b jacquard-1-10-stable-root This probably should have been an ordinary tag (without -b). If you really used -b, you should be able to convert it to a normal revision tag with: cvs tag -BF jacquard-1-10-stable-root -[simon]- cvs tag -b jacquard-1-10-stable-branch -[simon]- emacs README # to create an observable change -[simon]- ant install dist # to ensure I can build a working version -[simon]- cvs commit -m start of stable branch Unfortunately this fails: cvs server: cannot commit with sticky date for file `README' cvs [server aborted]: correct above errors first! The one step you left out is to switch your working directory to the newly-created branch: cvs up -rjacquard-1-10-stable-branch Once you've done that, your commit will succeed. -Larry Jones I don't need to improve! Everyone ELSE does! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: newbie
td writes: where can i find faq for that group? The starting point for all things CVS is: http://www.cvshome.org/ where can i find anything about encrypting the CVS storage content? CVS has no repository encryption support. Depending on what problem you're trying to solve, it may be possible to use some sort of encrypted file system for the repository. -Larry Jones Pitiful. Just pitiful. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Branch Numbers
SUBRAMANIAN, SARAVANAN (SBCSI) writes: How Branch Numbers are formed Internally in CVS. Branch numbers are formed by appending an even number to the number of the revision the branch is based on. Since revision numbers are file specific, a branch has different numbers in different files. I found out that one file is committed with 1.12.2.1 And other with 1.1.4.1 In the first case, the branch was based on revision 1.12 of the file and is the first branch for that revision (2 is the first even number). The branch number is thus 1.12.2. This is the first commit to that branch, resulting in revision 1.12.2.1. In the second case, the branch was based on revision 1.1 of the file and is the second branch for that revision (4 is the second even number). The branch number is thus 1.1.4. Again, this is the first commit to that branch, resulting in revision 1.12.2.1. -Larry Jones I hate being good. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
David Leskovac writes: If the cvs admin -n command renames branches why the need to delete the original branch name? What happens if you don't delete the original name? admin -n doesn't rename the branch, it just creates a new name for it. If you don't delete the old name, you can use either name to refer to the branch. There's nothing wrong with that, but it might be confusing. -Larry Jones It's like SOMEthing... I just can't think of it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
David Leskovac writes: Would this work for each branch to be renamed?: cvs rtag -b -r original_branch_name new_branch_name module No, that creates a new branch off of the existing branch rather than renaming the existing branch. You need to use admin -n instead. -Larry Jones Kicking dust is the only part of this game we really like. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
David Leskovac writes: Okay. So rather than the 2-step process I mentioned in my original post where I would create a new branch from the original branch then delete the original branch, there is a way to simply rename the existing branch with a cvs admin -n command? I looked at the syntax of cvs admin but it is not clear to me how this can be achieved. Would someone please provide an example? You still need a 2-step process, you just use admin -n to create a new name for the existing branch rather than using tag -b to create a new branch: cvs admin -n newname:oldname cvs tag -d oldname (Note that there's no radmin command so you need to have a checked out working directory.) -Larry Jones Hmm... That might not be politic. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Renaming a branch
David Leskovac writes: Okay. So, just to be clear, this is actually a 3-step process: 1. Checkout branch: cvs co -r branchname module 2. Rename from sandbox: cd to root of module in sandbox cvs admin -n newname:oldname 3. Delete original tag name sandbox: cd to root of module in sandbox cvs tag -d oldname Correct? Correct. I strongly encourage you to verify that step 2 has worked correctly before you move on to step 3, though. :-) -Larry Jones There's a connection here, I just know it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: About the cvs update error
Zhang, Jian-He writes: cvs update -P -C Headcount - 2H 05.xls (in directory C:\MyHouse\cvshome\Test\) cvs server: cannot open /user/guog/.cvsignore: I/O error Usually I/O errors imply a hardware problem of some sort. If that's an NFS-mounted directory, you might have a network problem or a problem with the NFS server. If not, you probably have a disk that's going bad. -Larry Jones Mom must've put my cape in the wrong drawer. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs and ldap
liz writes: I am exporting the CVSROOT variable. I suspect I am doing it correctly. Is there any way to tell what is going wrong during the authentication process? I haven't the foggiest idea where to look. If your syslog has an AUTHPRIV facility (check the man page), CVS logs more detailed information about authentication to it. -Larry Jones Mom would be a lot more fun if she was a little more gullible. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: sandbox on NFS-mounted directory?
Terrence Enger writes: I have seen lots of warnings against accessing a repository through an NFS mount. But I do not remember seeing any comments about accessing a sandbox through an NFS mount. It doesn't seem to be nearly as problematic and the consequences if there is a problem aren't as dire. BTW, Cederqvist 1.12.12 pages 97, 156, and 175 talk without warnings about checkouts over NFS and so forth, Are the earlier warnings in this group outdated? No, the manual just hasn't ever been updated to incorporate the warnings. -Larry Jones It's like SOMEthing... I just can't think of it. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Annotate binary files...
Andreas Volz writes: A! Perhaps I found the problem. I used another CVS server from another project. And there is works with binary files! Is the annotate version and binary stuff of the CVS *server* and not the CVS client a problem here? I'm not able to log in with a ssh server. Is it possible to get the CVS server version that I use with a client? Yes, that's the problem. The CVS client does very little processing, almost everything is done on the server. You can display both the client and server versions by using ``cvs version'' (not --version). The problematic server is running CVS 1.11.1p1, which is positively ancient and predates the change to avoid annotating binary files. -Larry Jones The game's called on account of sudden death. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Annotate binary files...
Andreas Volz writes: I had problems if I use cvs annotate in my project, because there are some binary files in the CVS. I marked the binary files with -kb. I think it should ignore binary files by default. It should. What does ``cvs status'' say about the problem files? -Larry Jones Apparently I was misinformed. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs add-ing large source tree
Jate Sujjavanich writes: I am having trouble cvs add-ing a very large source tree (500mb). I take the following steps: It's much simpler to just import it. -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: OT - Spaces in file and directory names (was: Alias syntax fo
Rick Genter writes: You mean point and click applications like WinCVS? No, I mean real point and click applications. WinCVS is just a point and click wrapper around a traditional application. -Larry Jones I don't see why some people even HAVE cars. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: OT - Spaces in file and directory names (was: Alias syntax fo
Jim.Hyslop writes: What I object to is the attitude spaces in file names are evil, the phrase that kicked off this (as you correctly pointed out) off-topic discussion. That attitude is outmoded, and reeks of a calcified mentality that refuses to accept change. Then let me rephrase the attitude: Funny characters (like spaces) in file names are nice and work well as long as you never use anything other than point and click applications, but they will cause you no end of grief if you ever use anything else, so they are best avoided. -Larry Jones I can feel my brain beginning to atrophy already. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: What should I do with CVS after IP address changed
Hong, Yi writes: It seems that the system was still trying to connect to the old IP address 141.106.32.35. Exactly. This is *NOT* a CVS problem -- it's a name resolution problem. Either the client system is using a hosts file that needs to be updated or you have a DNS problem you need to fix. -Larry Jones Philistines. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Alias syntax for a module that has a space in its name
Ed J writes: What is the syntax for creating a module alias when there is a space in the module name? There isn't one. -Larry Jones It's clear I'll never have a career in sports until I learn to suppress my survival instinct. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs add-ing large source tree
Jim.Hyslop writes: find's -depth argument may help; if I understand the man page correctly, it switches find from depth-first to breadth-first processing. No, -depth switches *to* depth-first processing. The default is pre-order traversal, which means that a directory is processed before its contents, but is not quite the same as breadth-first processing (breadth-first would require all directories at the same level to be processed before any of their contents). So either the original poster was confused or has a broken find command (or perhaps an alias that automatically adds -depth). -Larry Jones This game lends itself to certain abuses. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs add-ing large source tree
Jate Sujjavanich writes: My theory was wrong. A log file of the find ... -type f | xargs cvs add shows that it never schedules the missing file for addition. I'm not sure why yet. Do any of your files have spaces in the names? If so, find/xargs won't process them correctly (if you have the GNU versions, you can use find's -print0 operator and xargs's -0 flag to handle them correctly). If not, you may need to add an explicit -print operator to your find commands rather than counting on the default. It's still much simpler to just use import. -Larry Jones It's not denial. I'm just very selective about the reality I accept. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Alias syntax for a module that has a space in its name
Todd Denniston writes: My solution, put a simlink in the repo to the directory of interest, and in the modules file use the link. Note that this only works if you're not using LockDir= in your CVSROOT/config file. Otherwise, you defeat CVS's locking and put your repository at risk of corruption. [1] IMNSHO, spaces in file and directory names are one of the many evils in computers, remove them when possible and re-educate the creators (as much as you are allowed :). Exactly. -Larry Jones I thought my life would seem more interesting with a musical score and a laugh track. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: history command
dave frost writes: Could anyone tell me how to get user commit comments in the cvs history -e -a output ? Only by rewriting CVS. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Cvs and Solaris 10
Ryan Lea writes: Cvs is sgementation faulting when an import is run. I have tried this both remotely and locally on the machine with the cvs server. Can you use a debugger to get a traceback? -Larry Jones I'm getting disillusioned with these New Years. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: NEED HELP with CVS lock
Anthony writes: cvs commit -m testing test.pas cvs [commit aborted]: error writing to lock file //srv1/stor3/cvsroot/test/main/,test.pas, That file (//srv1/stor3/cvsroot/test/main/,test.pas,) is probably a remnant of the crash -- simply removing it should solve the problem. -Larry Jones Wh. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs import issues
Ryan Lea writes: This is a multi-part message in MIME format. Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! The actual checkouts/updates/add/commits etc all work fine. However, whenever 'cvs import' is run either remotely with :pserver: ... or locally the import fails and cvs seg faults. Please run a local import with tracing turned on (the -t global option) and post the results. -Larry Jones Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Severe speed problems with binary files
John Beranek writes: We use the CVS server via pserver, but generally the client is run on the server machine. Does it make any difference if you run in local mode rather than client/ server mode? -Larry Jones I kind of resent the manufacturer's implicit assumption that this would amuse me. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Severe speed problems with binary files
Russ Sherk writes: How many revisions of the example file are there? cvs speed may be affected adversly by a large number of revisions of a binary file. There doesn't necessarily need to be a large number of revisions, there just has to be a large number of differences, and that's almost certainly the problem. Although CVS can store binary files, it wasn't designed to do that and it doesn't work very well since its line- oriented diff algorithm usually doesn't work very well on binary files. In your case, you've got five distinct revisions of the file (1.1 and 1.1.1.1 should be identical) and the repository file is nearly five times the size of the working file, which indicates that the diff algorithm is not working well and lots of work will be required to regenerate old revisions. For those who don't know, the way the RCS file format (which is what CVS uses) works is the most recent revision is stored intact, all other revisions are stored as sets of differences from their base revisions. To recreate a particular revision, you retrieve the most recent revision and then apply the sets of differences to create each successive intermediary revision until you finally get the revision you want. The theory is that the most recent revision is the one you want most often, so retreiving it should be as fast as possible but retrieving other revisions can take longer. This generally works well as long as you're working on the trunk (since the most recent revision is defined as the head of the trunk), but breaks down as soon as you start working on branches since the head of the branch can be far removed from the head of the trunk. That is the situation you are in. You're working on a branch (albeit a vendor branch), so your head revision (1.1.1.5) is four (large) sets of changes away from the head of the trunk. If you try checking out revisions 1.1.1.1, 1.1.1.2, 1.1.1.3, 1.1.1.4, and 1.1.1.5, you'll undoubtedly find that each successive revision takes proportionally longer to check out. There are a couple of things you can do to improve the situation: 1) Don't store large binary files in CVS. 2) If you insist on storing large binary files in CVS, keep them on the trunk rather than in branches. For files on a vendor branch, you can force a commit to the trunk at the cost of making the repository file even larger and making old vendor releases more expensive to retrieve. 3) Rewrite CVS to better handle binary files. -Larry Jones Can I take an ax to school tomorrow for ... um ... show and tell? -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Severe speed problems with binary files
Jim.Hyslop writes: [EMAIL PROTECTED] wrote: In your case, you've got five distinct revisions of the file (1.1 and 1.1.1.1 should be identical) Should they? Normally. The only time they wouldn't be is if the file already existed when you did the first import. -Larry Jones Rats. I can't tell my gum from my Silly Putty. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problems updating rep
Eduardo Mendes writes: cvs add zzz.pdf xxx.doc yyy.xls cvs ci -m Adding doc and xls files cvs admin -kb zzz.pdf xxx.doc yyy.xls No problem so far, but when I try to cvs ci -m Updating a file, cvs returns: cvs commit: Examining . cvs commit: Up-to-date check failed for `zzz.pdf' cvs commit: Up-to-date check failed for `yyy.xls' cvs commit: Up-to-date check failed for `xxx.doc' cvs [commit aborted]: correct above errors first! What did I do wrong? You should have added the files in binary mode rather than adding them in text mode and then changing them to binary: cvs add -kb zzz.pdf xxx.doc yyy.xls If you're working on a platform that doesn't distinguish between text and binary files, all you need to do is update your working directory appropriately: cvs up -A If you're working on a platform that does distinguish between text and binary files, you'll still need to do that, but it will probably corrupt the files in your working directory so afterwards you'll need to replace them with fresh copies and commit them to get them stored correctly in the repository. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS I/O exception Message
DHARNA, AJAY [AG/1000] writes: Error validating location: I/O exception occurred: Connection refused: I HATE YOU Whether it is possible to either change or capture this message and then display a more appropriate message to the end user. Standard CVS has no such error message (the I HATE YOU is a defined part of the CVS client/server protocol that cannot be changed, but standard CVS only uses it internally, it never displays it to the end user). You should ask whoever supports the particular CVS client you're using. -Larry Jones I never get to do anything fun. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: no such repository
Jim.Hyslop writes: You can have as many '--allow-root' options in your (x)inetd.conf file as you want. Well, I suppose there is some upper limit, but for practical purposes it's probably much higher than any sane person would use :=) Not necessarily, many inetds have a ridiculously low limit on the number of server arguments (like 8) which is why the manual explicitly mentions the problem and the obvious solution (run a shell script). -Larry Jones My upbringing is filled with inconsistent messages. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Check time of tagging
Euan Guttridge writes: Is it possible to produce a list of all files with a specific tag Yes, see the various log/rlog options, particularly -r and -S. and the time each file was tagged (not commited, tagged)? No, CVS does not timestamp tags. -Larry Jones Your gender would be a lot more tolerable if it wasn't so darn cynical! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Large CVS Installations
DHARNA, AJAY [AG/1000] writes: I would like to know whether you have a 1 disk volume mounted to multiple CVS server machines or whether you prefer to do it is another way and why you think that that method is more efficient. Essentially *every* instance of repository corruption we've encountered over the years has been caused by NFS interoperability bugs. I'd think very carefully before putting a repository on an NFS mounted disk. -Larry Jones Moms and reason are like oil and water. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Merge issues with CVS
SUBRAMANIAN, SARAVANAN (SBCSI) writes: We use branches in CVS, When we do merge the conflicted files which are merged earlier appears again and again. How to solve this issue. Don't keep merging the same changes over and over: https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_5.html#SEC61 -Larry Jones Please tell me I'm adopted. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: third-party sources sharing same directory
Vitor writes: And an second third-party source also is added into the same dir, creating some files in HERE and creating some subdirs. Is this an problem ? Only if there's a name conflict between files in the two different third-party sources. But why would you want to put two apparently unrelated things in the same directory? It seems like you're just asking for trouble in the future. -Larry Jones From now on, I'm devoting myself to the cultivation of interpersonal relationships. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs -n up request to remove '?' entries
Paul vL writes: I'm a happy cvs user for many years. One of the more annoying things however is the behaviour of cvs -n up for large working directories; I use a global -q option to trim down output, but still get an enormous list (200+) of '?' before I get my one or two 'M' entries. Have you considered adding a .cvsignore file to explicitly ignore the extra stuff? -Larry Jones What a stupid world. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs import problem
C.G.Senthilkumar. writes: 3. I tried to import a project from machine A into the repository on machine A itself locally. cvs failed saying can't create myproj directory, permission denied. Check the ownership and permissions of your repository directories -- the user you were running as doesn't have permission to create the directory you were trying to import into. 4. I tried to repeat the last part except I set CVS_RSH=ssh and used cvs -d :ext:[EMAIL PROTECTED]:/usr/local/repos even though I was importing in a local machine. And surprise! this trick worked. That implies that you were not logged in as user when you tried the local import. -Larry Jones I always have to help Dad establish the proper context. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Odd typo in update message?
Thomas Maier writes: Well-establishing this way of quoting was probably the Wrong Thing to do; No, it was not. Markus Kuhn either doesn't know or chooses to ignore that this convention long predates things like the X Window System and its fronts, going all the way back to the original ASCII standard (1968) if not before. No matter how much Unicode proponents wish for all other coded character sets and typographic conventions to go away, that is *not* going to happen any time soon. Using the convention was not an inadvertent mistake, it was a deliberate decision. -Larry Jones These child psychology books we bought were such a waste of money. -- Calvin's Mom ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: corrupted RCS-files with x0
Claudia Peter writes: we moved our cvs-server from solaris to linux and since then we got corrupted RCS-files. The symptoms are always the same: in the *,v-file are after the desc @@ are a lot of x0 (the number of x0 changes). That certainly *sounds* like the typical NFS corruption -- if you dump the repository file, is the string of zeros an integral number of disk blocks long and on a block boundary? (Disk blocks are usually 512 or 1024 bytes long.) If so, then there's almost certainly a serious bug in the relevant file system code or the disk subsystem. The files get corrupted when checking out or tagging. Checkout doesn't modify the repository file so it's impossible for checkout to *cause* corruption, although it will certainly report it if it exists. Any hint will be helpfull If you can reproduce the problem, it would be helpful to see a repository file both before and after the corruption. -Larry Jones Is it too much to ask for an occasional token gesture of appreciation?! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Odd typo in update message?
Mark E. Hamilton writes: Is this in fact a typo, or is there some other meaning/use for this `name' pattern? It's a well-established way of simulating ``real'' (typesetting) quote marks using only standard ASCII characters. In fact, the original ASCII standard even named the two characters LEFT SINGLE QUOTATION MARK and RIGHT SINGLE QUOTATION MARK in addition to their other names. Many fonts display them symmetrically, but alas many do not. CVS has used the convention inconsistently in its messages, I believe Derek has made a concerted effort recently to use them more consistently. -Larry Jones I keep forgetting that rules are only for little nice people. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: configuration permissions
=?iso-8859-1?q?Gleidson=20S=E1=20Barreto?= writes: How do you do to restrict the level of access to the modules of the project? https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC13 -Larry Jones I'm not a vegetarian! I'm a dessertarian. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Failied to access the CVS repository
MEI-XING ZHAO writes: $ cvs log file1 can't create temporary directory /tmp/root/cvs-serv4896 Permission denied You don't have permission to create subdirectories in /tmp/root (on the server), which is apparently where you have the server's temp directory set to: https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC37 -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Failied to access the CVS repository
MEI-XING ZHAO writes: Thanks for your reply Larry. You are correct about the problem. I found I can access the CVS repository locally(on the same server) OK. But run cvs command remotely still not working. I am not sure where the /tmp/root set set. It use to be just create the temp files on /tmp. What has most likely happened is that someone has changed $TMPDIR for root to be /tmp/root and that setting is getting inherited by everything that root starts, including [x]inetd and then CVS. Check your [x]inetd config file against what's shown in the CVS manual: https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC30 If that doesn't help, add an explicit ``-T /tmp'' before ``pserver'' to the CVS command in [x]inetd.conf. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Failied to access the CVS repository
MEI-XING ZHAO writes: BTW, any way to reinitilize the changes made in inetd.conf without rebooting the machine? Probably -- ``man inetd''. -Larry Jones I've got more brains than I know what to do with. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Checkout after a change
[EMAIL PROTECTED] writes: The example they give is with unix, how would I do it with linux That's like asking how to drive a Toyota Corolla given that you only know how to drive a Honda Civic. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Jim.Hyslop writes: Not sure where you heard that, but it will cause you much more work. I use symlinks in the repository, with no problems. What kind of symlinks? Although it's not recommended, you can symlink *directories* in the repository, as long as you don't use LOCKDIR in your config file to put the lock files somewhere else. If you do, or if you symlink individual files, you're completely defeating CVS's locking scheme and opening yourself up to all sorts of potential corruption. -Larry Jones OK, there IS a middle ground, but it's for sissy weasels. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Jim.Hyslop writes: Oh, and doesn't CVS have problems if $CVSROOT/CVSROOT is symlinked? Or has that been fixed? I believe that's been fixed. -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Again: multiple vendors
Baurzhan Ismagulov writes: 1. Added and deleted files: I have to track them manually when I apply the delta for a new upstream release. I have to grep for 1970 and add / remove the files. That shouldn't be necessary -- a normal merge using two revision tags should note and process added and deleted files correctly. -Larry Jones Mom must've put my cape in the wrong drawer. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: help with configuration of activitymail
Parvinder Singh Arora writes:
my loginfo entries
ALL /usr/bin/activitymail -D -c -f %1{sVv} -p -u [EMAIL PROTECTED] -t
[EMAIL PROTECTED]
The %1{...} syntax only works with CVS 1.12.x. For CVS 1.11.x, get rid
of the 1.
-Larry Jones
I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problems after moving CVS repository.. HELP
[EMAIL PROTECTED] writes: We recently moved our CVS repository to another directory on the same HPUX box. Security remainded identical on all files.. No, it didn't, or you wouldn't be having problems. Either the ownership or the permissions got changed, or you don't consider directories to be files. In fact, it looks like the directory permissions are the problem -- do you intend that anyone in the dev group should have full read/write access to the repository? If so, you need to set group write permission on all the directories in your repository. Also, other has read permission on all the directories but not execute, which doesn't make any sense; you should give other execute permission or remove the read permission. -Larry Jones Philistines. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Problems after moving CVS repository.. HELP
[EMAIL PROTECTED] writes: cvs checkout: warning: cannot write to history file /aacustom/cvs/CVSROOT/history: Permission denied The history file permission should be set so that it's writable by all CVS users. I'm almost certain security remained the same. Somehow we were able to check in and out without having write access to these directories... Did you change CVS executables? If so, then perhaps the old executable was running set UID or set GID. Another possibility is that there were ACLs on the old repository files that were granting permissions but didn't get copied to the new location. I don't want to be able to do the following as any old user: I suggest you study the section of the manual on permissions: https://www.cvshome.org/docs/manual/cvs-1.12.11/cvs_2.html#SEC13 -Larry Jones I hope Mom and Dad didn't rent out my room. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS concept of time - time zone part 44!
Todd Denniston writes: Will there be an option I can put in my _ environment _ so all CVS commands client will show UTC times? Most systems honor $TZ. -Larry Jones That gives me a FABULOUS idea. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server times
rakesh mailgroups writes: does anyone know if the repository server having a different time than local PCs will cause issues with CVS? It shouldn't. -Larry Jones I can do that! It's a free country! I've got my rights! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
