Re: CVS problem with ssh
Richard M. Stallman writes: We may have to send bug reports for the systems where it does not always work. That's essentially *ALL* of them. How many time do I have to say it -- nonblocking mode violates the fundamental assumtions about how files are supposed to behave and virtually *no* code, including stdio libraries, handles it unless it sets nonblocking mode itself. Nor should it, in my opinion. -Larry Jones The hardest part for us avant-garde post-modern artists is deciding whether or not to embrace commercialism. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS problem with ssh
Richard M. Stallman writes: If you prefer a different fix that _can be done by us_, that's fine with me. Just as long as we fix the problem. WE CAN'T FIX THE PROBLEM. Nothing you do to the car can fix the potholes in the road. You can spend all the time and money you want upgrading the suspension to try to smooth out the ride, but you're still going to destroy tires if the road is bad enough. If you want to fix it, go figure out how to fix ssh and submit a patch. Or convince the ssh maintainers to do it. Here's evidence that it affects things other than CVS: $ cat bigfile | wc -c 11458815 $ (ssh localhost sleep 10 sleep 3; cat bigfile) | wc -c cat: stdout: Resource temporarily unavailable 266240 ssh and cat are sharing the same stdout, so when ssh in the background sets nonblocking mode, it screws up cat in exactly the same way as it screws up CVS. -Larry Jones The living dead don't NEED to solve word problems. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS + SSH Connection refused
Bitter, Ingmar (NIH/CC/DRD) writes: On my beowulf cluster login node the installed system CVS is 1.11.1p1 and doing a 'cvs up' or any other cvs command results in: cvs -d :ext:[EMAIL PROTECTED]:/raid/cvsrepo up xxx.xx.xx.xxx: Connection refused Older versions of CVS default to rsh for :ext: connections rather than ssh. You just need to set $CVS_RSH to ssh. -Larry Jones Even if lives DID hang in the balance, it would depend on whose they were. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS problem with ssh
Richard M. Stallman writes: If this is what it takes for you to fix the bug, I will do this. Instead of spending large amounts of effort on half-assed workarounds, why don't you make a concerted effort to explain the problem to the OpenSSH developers and encourage them to fix the actual problem? As far as I can tell, no one has actually bothered to do that, which leads me to believe that it's not really a serious problem for anyone. -Larry Jones I'm not a vegetarian! I'm a dessertarian. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
OpenSSH and non-blocking mode
Dear OpenSSH developers, OpenSSH setting non-blocking mode on its standard files creates serious problems. Setting non-blocking mode violates many of the semantics of how files are supposed to behave and most programs (and most, if not all, stdio libraries) are not prepared to deal with it. That wouldn't be a problem except that non-blocking mode is not a property of the file descriptor but a property of the underlying file table entry and thus affects *all* file descriptors that are bound to that file table entry, not just the one used to set non-blocking mode. Thus, you really shouldn't use non-blocking mode unless you're in complete control of the underlying file. Since the standard files (stdin, stdout, and stderr) are inherited from the parent process, that's never the case. Consider: $ cat bigfile | wc -c 10858893 $ (ssh localhost sleep 120 sleep 3; cat bigfile) | wc -c cat: stdout: Resource temporarily unavailable 270336 When ssh puts its stdout into non-blocking mode, it also puts cat's stdout into non-blocking mode. cat notices the problem, but doesn't actually handle it correctly (most likely because it's using stdio and thus *can't* handle it correctly), so the vast majority of the data just disappears into the bit bucket. I understand the necessity to keep ssh from blocking in order to keep port-forwarding working, but wouldn't it be possible to do that by just selecting for write before trying to write to stdout or stderr rather than setting non-blocking mode? -Larry Jones My brain is trying to kill me. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs in Suse 9.3
Massimo De Melis writes: cvs [command aborted]: connect to server(server IP):2401 failed: Connection refused That's covered in the manual: https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_21.html#SEC189 -Larry Jones Wh. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS problem with ssh
Richard M. Stallman writes: I'm glad to hear that the new CVS version has a fix that may prevent the problem. Maybe this problem is fixed now. But we should verify that. It's not a fix, it's a temporary workaround that avoids the problem in some, but not all, cases. It's possible that this fix is a full and correct solution. If the descriptor has room for at least one byte, `write' won't return EAGAIN; it will write at least one byte. It may write less than the whole buffer that was specified. If the stdio code handles that case correctly, the results should be correct. That depends on your definition of correctly. I suspect that all stdio implementations handle short writes by immediately doing another write for the remaining data, which in this case will immediately fail with EAGAIN and we're back to where we started. If the current fix does not make it correct, please do make the larger fix--do your own buffering. That is surely not really a large job. Replacing stdio isn't a large job?!? As this case shows, other processes that share the descriptor have the reasonable expectation that they can take an inherited descriptor and make it non-blocking. That is an entirely *un*reasonable expectation. Like I said before, nonblocking mode does not affect the descriptor, it affects the underlying file and it violates all of the conventions of how files are supposed to behave. Thus, it cannot reasonably be used except under very tightly controlled conditions -- when you know that you have exclusive use, not just of the descriptor, but of the underlying file. Typically, it's used on newly-created sockets, which do satisfy those conditions. Ssh is trying to use it on standard descriptors that it inherits from an unknown source that almost certainly do not satisfy those conditions. That's just plain wrong. Note that rsh has always worked just fine without using non-blocking mode for *anything*, ssh should certainly be able to get away without using it on its standard files. Rather that deciding what to fix by first placing blame, we can do better if we look at how we can contribute to making the system work. Agreed, which is why we adopted the workaround. But it's not placing blame, it's determining the root of the problem. The right program to fix, in a case like this, is whichever one we actually can get fixed. No, the right program to fix is the one that's broken: ssh. -Larry Jones Whatever it is, it's driving me crazy! -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: CVS problem with ssh
Richard M. Stallman writes: I am trying to bring about a fix for the bad interaction between CVS and SSH that causes data to be lost? See http://lists.gnu.org/archive/html/bug-cvs/2002-07/msg00423.html for a good explanation. After studying that message, I think I understand the problem. It occurs when the stdout of cvs equals the stderr of ssh. When ssh sets O_NONBLOCK on that descriptor, cvs gets confused. The key thing to understand is that O_NONBLOCK does not affect the *descriptor*, it affects the underlying *file*. Thus, if other descriptors are bound to the same file, they also become non-blocking. This problem has gone unfixed because neither CVS nor SSH is doing something clearly wrong. Nonetheless, the combination of the two are doing something wrong, so we need to fix it somewhere. To my mind, SSH *is* doing something clearly wrong. See: http://lists.gnu.org/archive/html/bug-cvs/2004-08/msg00166.html Couldn't this be fixed easily by changing cvs to handle EAGAIN in a simple way when outputting to stdout? No, because CVS uses stdio for output to stdout and thus the response to errors is out of its control. And most extant stdio libraries do not handle EAGAIN. -Larry Jones In a minute, you and I are going to settle this out of doors. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs client: refetching unpatchable files
James Croxford 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 version of the CVS command we have is 1.11 That version is ancient -- the current stable release is 1.11.20! I strongly suggest upgrading both the client(s) and the server (although the server is most important): http://www.cvshome.org/. That may well fix the problem. I need to understand why a patch would fail, or at least some of the possible reasons, and ideally would like to fix this so the patch works if at all possible. The usual reason is that something has changed the file without changing the timestamp. * Disclaimer Such disclaimers on messages sent to public mailing lists are silly at best. Please give your lawyers a cookie and put them in a nice padded room where they won't hurt themselves or annoy others. -Larry Jones The living dead don't NEED to solve word problems. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] New GNULIB glob module?
Derek Price writes: Larry, can you tell us if defining _POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of getpwnam_r on Solaris? It looks like it. -Larry Jones I never get to do anything fun. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: GZip level restriction
Derek Price writes: I discussed adding a compression level restriction on the server as a work-around for another bug that has since been fixed a few months back. I don't think hard restrictions are a good idea. The best compression level depends on the total system: the server machine, the client machine, and the communication path between them. The server doesn't know enough about the whole system to impose absolute restrictions. If I'm at the other end of a 300bps phone line, I want -z9 no matter how much CPU time it takes. If I'm trying to debug the connection, I want -z0 even if the server is at the other end of a 300bps phone line. Since the client is most likely to have an intelligent operator behind it who *can* determine the properties of the entire system, I think the server should always try to provide what the client asks for. On the other hand, it would be nice if there were a way to specify a default compression level or range of levels (both for the server and the client) that could be used in the absence of any explicit specification by the user. Of course, reconciling conflicting defaults could be an interesting challenge. -Larry Jones Philistines. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] Re: getopt and Solaris 10
Derek Price writes: Okay, looking at that in C89 now, but just out of curiosity, if argv needs to be NULL terminated, what's the point of argc? I believe it was added for convenience back in the dark ages. All the Unix exec functions require a null-terminated argument list (and don't have an explicit argument count), so argv has naturally always been null terminated. (And the C Standard codified that behavior: at program startup, argv[argc] is required to be null.) -Larry Jones I don't think that question was very hypothetical at all. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: what should I do with IP readdress of test server
Hong, Yi writes: cvs [update aborted]: connect to cvs-rep(141.106.32.35):2401 failed: Connection timed out Is that the new IP address or the old IP address? If it's the old IP address, you have a DNS problem, not a CVS problem. If it's the new IP address, then either [x]inetd isn't configured correctly or you have a software or hardware firewall that's blocking the connection. -Larry Jones The surgeon general should issue a warning about playing with girls. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: some files are missed in importing
Jim.Hyslop writes: [EMAIL PROTECTED] wrote: (Hmmm, question: can a .cvsignore ignore .cvsignore ?) Yep. But note that that only keeps CVS from marking it as an unknown file, it still honors the contents of the file (obviously). -Larry Jones Isn't it sad how some people's grip on their lives is so precarious that they'll embrace any preposterous delusion rather than face an occasional bleak truth? -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: some files are missed in importing
root writes: when I typed this command, some important files are ignored [...] what should I do to solve this problem? That's hard to say. It looks like you're trying to import a CVS working directory (hopefully, one from another system). You can't actually import the CVS subdirectories without hopelessly confusing your CVS. The other files are probably listed in .cvsignore files in their containing directories -- you can import them by temporarily deleting the .cvsignore files, doing the import, then replacing the .cvsignore files and doing the import again to get the .cvsignore files. -Larry Jones I thought my life would seem more interesting with a musical score and a laugh track. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: lib/xtime.h is included twice
Jim.Hyslop writes: Since this is such a small patch, should I still update ChangeLog and NEWS? All changes go into ChangeLog, only significant user-visible changes go into NEWS. See the GNU coding standards for more details: http://www.gnu.org/prep/standards/ -Larry Jones The game's called on account of sudden death. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: [bug-gnulib] GNULIB wait-process module.
Bruno Haible writes: 2) The very idea of a parent process being responsible for helping debug the child process makes me shudder, because it makes it hard to replace the parent or the client program. In this particular case (CVS), the child process is ostensibly a copy of the parent executable, so that isn't a problem. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Mark D. Baushke writes: I have no objections to .origin being used for the very first revision of the mainline. Why bother with a special name? Just use .trunk.root. -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Feature request/ideas
Derek Price writes: I'm not sure what I would recommend in place of what you are calling the root, but I would like to see .root refer to the revision on the parent branch. As far as I can see, what Frank is calling the root is meaningless in CVS. I'd just get rid of it. -Larry Jones Temporary insanity! That's all it was! -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: log between tags
Tommaso Massimi writes: I made a lot of commit on a file between two tags, but if I try to run cvs log -r tag1::tag2 filename [...] I can see ony the comment of the last commit I made. If you're running client/server, then perhaps your server is too old. If not, then I suspect that you did not actually have a lot of changes between the two tags, because that command has worked fine for a couple of years, now. Try ``cvs status -v'' on the file and see what revisions the two tags are attached to. -Larry Jones Philistines. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs edit error for directories that contain an invalid character
David writes: I've seen an old issue (#127), related to this error/bug, but it still happens in the current stable release. Has it been forgotten or something? No, it's just a very big job to fix (the entire watch/edit function needs to be redesigned while still remaining backward compatible) and no one has been motivated to do it yet. -Larry Jones Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs is slooooooow with large directories
Andrew Morton writes: On a dual 2.7GHz power4, the cvs client has racked up an hour of CPU time so far. There's something in there which is quadratic (or worse) in the number of files in a directory. Yes, the fix for a release problem that Derek made a year ago (2004-02-25) is responsible for this behavior. Prior to that fix, CVS would cache the Entries for a directory so that it wouldn't have to read (and possibly rewrite) the Entries file for each file being processed. Unfortunately, it sometimes changed to a different directory without flushing the cache, resulting in one directory's Entries ending up in a different directory. Derek's fix removed the cache, so each new file being checked out ends up reading the Entries file, adding the new file, and then writing it back out, which is indeed quadratic behavior. We need to figure out a way to restore the cache without reintroducing the original problem, a non-trivial task. -Larry Jones He piqued my curiosity. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: 'cvs watch on' patch
Jim Hyslop writes: While I'm at it, I think I'll look into the discrepancy between documented behaviour of the 'cvs watch' commands and the actual behaviour. According to the documentation, if files mentions any directories, it should set the default attributes for that directory; cvs 1.11 only sets default attributes if files is omitted. I don't object to the behaviour, but it will make it difficult to implement any rwatch command in the future, since the rwatch will require a file or module specification. Which is why I think the documentation is right and the code is wrong. -Larry Jones It's hard to be religious when certain people are never incinerated by bolts of lightning. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
[EMAIL PROTECTED] writes: What, if I check out test/sub1 and test/sub2 in two different directories and then move the sub2 into the sub1 directory? Shouldn't this produce the same results as with the two different checkouts as shown below? Whether it should or not is open to debate, but it does not. If you manually move one CVS controlled directory into another CVS directory, CVS will not recurse into the subdirectory when operating in the parent directory because it recorded all the known subdirectories of the parent in the Entries file and doesn't go looking for new ones that appeared by magic when it wasn't looking. -Larry Jones Buddy, if you think I'm even going to BE here, you're crazy! -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
[EMAIL PROTECTED] writes: sub1/ + sub2/ Situation a) You have checked out sub1 and sub2 from the same repository (but different locations in it). Invoking 'cvs update' in sub1 dives into sub2. Invoking 'cvs update sub2/file2.txt' fetches the file. This is the correct behavior regardless of whether sub1 and sub2 come from the same repository or different repositories. Situation b) You have checked out sub1 and sub2 from two different repositories (e.g. one pserver and another ext). Invoking 'cvs update' in sub1 only processes the sub1 directory. Invoking 'cvs update sub2/file2.txt produces an error message. *WHAT* error message?!? How do you expect us to help you when you won't tell us any details about the error? I cannot reproduce your problem with CVS 1.11.19 -- situation b works just like situation a, as it should. Please recreate the problem using ``cvs -t'' to get a trace and post the results. -Larry Jones We don't ATTEND parties, we just CRASH 'em. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
[EMAIL PROTECTED] writes: I thought, in this case it was crystal clear: something like sub2/file2.txt is not available in the repository, because the sub2-stuff comes from a different repository than the one from the current working directory (sub1). No, it's not crystal clear, because CVS has handled multiple repository working directory trees for a long time. We need the exact error message along with a trace to figure out what's going wrong. -Larry Jones I think we need to change the rules. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
[EMAIL PROTECTED] writes: And exactly this is the core problem. I don't see a difference between checking out two different projects on into the other or checking them out into two different directories and moving them on into another. I also can move any project root to some other location on my disk and any CVS command works. Why not in this situation? Because somewhere along the way, one of the CVS developers thought that it was a small price to pay to avoid having to scan the entire directory for newly created, moved, or renamed subdirectories to recurse into every time you issue a CVS command. It also allows CVS to ignore any subdirectories that your build process creates rather than trying to recurse into them. I don't think it's unreasonalbe to expect you to use CVS commands to manipulate the contents of CVS-controlled directories rather than expecting CVS to figure out what you intended when you changed things around behind its back. -Larry Jones Pitiful. Just pitiful. -- Calvin ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Wish: Turn on compression through environment variable.
Thomas Roessler writes: It would be nice if the effect of cvs -z9 could also be accomplished by setting an appropriate environment variable. Why would that be better than putting it in your ~/.cvsrc file? -Larry Jones It's SUSIE! It's a GIRL! Santa would understand! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS 1.11 builds under QNX Neutrino 6.20, but fails binfiles-6test
John Nagle writes: MIME-version: 1.0 Content-type: multipart/mixed; boundary=Boundary_(ID_+1awH8yRco8bOZakQMkU9A) Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! This test should produce no other output than this line, and a final OK. FAIL: binfiles-6 You may want to read TESTS if you haven't already. PASS: binfiles-5.5b1 ** expected: Checking in binfile; /tmp/cvs-sanity/cvsroot/first-dir/binfile,v -- binfile new revision: 1\.2; previous revision: 1\.1 done ** got: FAIL: binfiles-6 Looking at the test, that implies that CVS didn't realize that the file had changed and thus didn't do anything. You'll need to figure out why that is. Does QNX's filesystem have a 1 second granularity on file timestamps like Unix or a 2 second granularity like DOS? If the latter, then that is almost certainly the problem -- CVS assumes that a file cannot change without it's timestamp changing and assumes a one second delay is sufficient to ensure that. To work around the problem, you can add sleep 1 commands to sanity.sh as required. -Larry Jones From now on, I'm devoting myself to the cultivation of interpersonal relationships. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2-FreeBSD stuck at 100% CPU
Henrik Nordstrom writes: at squid-cache.org we have a problem with cvs server processes getting stuck att 100% CPU and needing to get killed by kill -9 to go away. A nice kill -TERM or kill -HUP does not help. There's a known incompatibility between CVS 1.11.2 and previous clients when using compression that causes a hung server with no CPU utilization. There's another known bug that causes the server to go into an infinite loop when a signal is received under certain circumstances. Both of these problems are fixed in the current development version of CVS that you can get from the repository at www.cvshome.org. -Larry Jones Whatever it is, it's driving me crazy! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2-FreeBSD stuck at 100% CPU
Henrik Nordstrom writes: Should I get the head version, or is there a 1.11 something branch I should be using? Just get the head, the other changes should all be more bug fixes. It will probably become 1.11.3 sometime soon. -Larry Jones Rats. I can't tell my gum from my Silly Putty. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs rlog to cvs.cvshome.org fails with assertion failure
Henrik Nordstrom writes: Using cvs 1.11.2 cvs -d :pserver:[EMAIL PROTECTED]:/cvs rlog ccvs cvs: lock.c:178: lock_name: Assertion `(__extension__ (__builtin_constant_p ( st rlen (current_parsed_root-directory)) ((__builtin_constant_p (repository) [lots of conditions snipped away for clarity] cmp (repository, current_parsed_root-directory, strlen (current_parsed_root-di rectory == 0' failed. The path to your CVSROOT contains a symbolic link, which confuses CVS. If your system supports loopback mounts, use that instead of a symbolic link. If not, you'll have to use the real path to the repository or live with the errors. There have also been a number of patches posted if you want to consult the archives and experiment with one or more of them. -Larry Jones It's a Doofus Ignoramus! Our hero slowly reaches for his stun blaster! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvswrappers file
Da Costa Martins, Iolanda Maria writes: Is the cvswrappers admin file case sensitive Meaning: if I declare .xml will it also cover .XML (example)?? No. To get all possible permutations, use .[xX][mM][lL]. -Larry Jones Mom must've put my cape in the wrong drawer. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: query!
Shaktinath Pandey writes: MIME-Version: 1.0 Content-Type: multipart/mixed; Please do not post MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! I want to create some empty versions . e.gsuppose the trunk line is 2.0 and I check in the latest modification as 5.0 usingcvs commit -r 5.0 sample.c this creates the version 5.0 without creating 3.0 and 4.0. I want 3.0 and 4.0 to be created automatically. No, you don't. Revision numbers are for CVS internal use only -- you should learn to ignore them. Use tags to provide meaningful release identifications. -Larry Jones Girls are so weird. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: (no subject)
Peter Meszaros writes: After issuing the following command (the leading zero is the point): $ cvs ci -r 080.1 the appropriate CVS/Entries file will contains dummy timestamp timestamps. Therefore the cvs ci command will always find those files in the future, even if they haven't been modified at all. I've checked in a fix for this bug. Thanks! -Larry Jones Hmm... That might not be politic. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs-1.11.2: commit across multiple dirs -- log messages lost
Bolo writes: Multi-directory commits and message edits don't work in cvs-1.11.2. That's already fixed in the current development version of CVS, but thanks anyway! -Larry Jones Some people just don't have inquisitive minds. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs server 1.11.2 memory leak
Michel Marti writes: I noticed that while cvs server is waiting for a lock (due to stale lock file(s)) and you hit cancel on the IDE (or the ssh connection drops), cvs server quickly eats up all available memory leaving the system in a very unstable state: System load average goes up to about 11, and top shows that the cvs process is eating 97.3% memory. That should be fixed in the current development version of CVS. -Larry Jones I hope Mom and Dad didn't rent out my room. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: 1.11.2 server hangs older clients on -z
Artur Klauser writes: It seems that any clients older than 1.11.2 (I tried 1.11.1p1 and 1.10.8) hang indefinitely at the end of the remote connection IFF a -z option is used in the cvs command. This is for a remote (SSH, RSH) client/server environment. 1.11.2 clients did not experience this problem. Also, the same cvs commands without compression (-z) complete correctly. Yes, lots of people have noticed this. As I just said in another message, it's fixed in the current development version of CVS. -Larry Jones Girls are like slugs -- they probably serve some purpose, but it's hard to imagine what. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: missing #ifdef in logmsg.c
Dr. Weth Christopher writes: building cvs 1.11.2 without client support fails, the problem is this (logmsg.c, line 198): That's already fixed in the current development version, but thanks anyway! -Larry Jones Rats. I can't tell my gum from my Silly Putty. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 rdiff fails with binary files
Derek Robert Price writes: Do you have a good reason we shouldn't allow this, other than it isn't accompanied by appropriate test cases and maybe documentation? It seems to me that there isn't any good reason for rdiff to fail this way. It would seem to me to be best to match the diff behavior here. I don't necessarily object to the principle, but I'm not so sure about the mechanism. It seems to me that it would be better to detect the message from diff (like patch_file in update.c does) rather than just punting any binary file (some binary files *are* diffable, after all). Also, do you know of any issues where rdiff behavior intentionally differs from that of diff? I fixed diff some time ago to generate proper patches, so it seems to me that any behavior differences should perhaps be merged as much as possible in the vein of tag rtag. If you don't know the answer off of the top of your head, don't worry about it, of course. I should get around to reading the source later. Not off the top of my head, other than the significantly different command line parsing. I think merging patch.c into diff.c and unifying as much code as possible would be a very good thing. I have mixed feelings about unifying the command lines. On the one hand, it would be handy to have a real rdiff that accepts all the diff options, but there are conflicts with the existing patch (aka rdiff) options which are themselves quite useful. -Larry Jones I think we need to change the rules. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 rdiff fails with binary files
Derek Robert Price writes: Hrm. `-s' would seem to be roughly equivalent to diff's `--brief', so Only roughly -- the output format is quite different (I would argue that patch's is much nicer). Don't forget that people have been known to parse the output from CVS. you mean `-t' to generate a patch between the last two revisions is useful? That too. I suppose we'd be removing rdiff's default implication of `diff -uN', but that could be replaced with the addition of a `--patch' option to `cvs diff' as a shortcut for `-uN'. Actually, the default is -cN (sort-of; patch creates the empty file itself rather than passing -N to diff). Think of the problems changing the default would cause both for users (who type without thinking) and for scripts. Perhaps we should consider splitting patch from rdiff rather than having them be synonyms. Unfortunately, rdiff is the canonical name and that's the one we'd want to change the behavior of. -Larry Jones Even my FRIENDS don't do what I want. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Bug: remote repository zombies
Artur Klauser writes: The Problem: - John and Paul are happily developing. John is removing file bar and commits this change. Paul in the meantime is changing his file bar, later does an update (to get John's changes) and then does a commit. - The problem is that Paul's update goes through and leaves his local file bar in 'Locally Modified' status, rather than failing with 'Unresolved Conflict'. What version of CVS are you running on the client and server (cvs version)? It seems to work right for me in 1.11.2. -Larry Jones My dreams are getting way too literal. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: (no subject)
[EMAIL PROTECTED] writes: It seems that in some parts of the CVS source there is an assumption that a zero major rev indicates an out-of-sync file. Other parts of the code do not seem to make that assumption. I found it suggested, but not stated, that CVS wants all projects to start at 1. (I did not read *all* of the available CVS documentation, so I may have missed it. I did check the FAQ at Cederqvist...) Personally, I like to start at zero when I am working with very new code. As a result, I get bit by this a lot. In CVS, the revision numbers are really just for internal use. You will save yourself a lot of grief if you learn to ignore them and let CVS use them however it wants. If you want revision numbers that are meaningful to you, embed them in tags. -Larry Jones At times like these, all Mom can think of is how long she was in labor with me. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: MODIFIED: src ...
Derek Robert Price writes: What happens right now if two tag readers are trying to upgrade to write-locks at the same time? Can they both have a read lock in the same directory and thus each prevent the other from upgrading to a write-lock? Right now, that code has been replaced due to that exact problem (which of course didn't occur to me *before* I checked in the change, only afterwards). Now, start_recursion takes a locktype argument that tells it whether to read or write lock each directory as it's processed. -Larry Jones See if we can sell Mom and Dad into slavery for a star cruiser. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: MODIFIED: src ...
Derek Robert Price writes: Seems to me an I'm waiting to upgrade to a write lock lock would work just as well. Such a lock could prevent the creation of any other locks and other readers waiting for an upgrade could release their read locks in preference of the first server with an upgrade lock. I haven't studied the problem though. Would that be any more efficient than what you did? Probably not, and I don't think it can be made to work in the current scheme anyway. The original problem was that it was start_recursion() that read locked the directory but it was the call-back function that wanted the write lock. In that architecture, the call-back function can't release the read lock because it doesn't own it, and even if it could, it wouldn't work because there's cached data in the RCS library that could become invalid if you released the lock and there's no way to flush that cached data. -Larry Jones Philistines. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Bug in Expr 2.0.12 - .* too greedy
Derek Robert Price writes: The expr, version 2.0.12, which happens to be distributed with RH Linux 8.0 is broken. .* is way too greedy. Here's a test case: FWIW, the oldest 2.0.x I can find is 2.0.13 and it seems to work correctly, so I'm guessing the bug didn't last long. RH just picked an unfortunate version to distribute. -Larry Jones Monopoly is more fun when you make your own Chance cards. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs-1.11.2
Eric Lassauge writes: I recently downloaded and compiled cvs on an old HP-UX system (HPUX 10.20)localized for french language (LANG=fr_fr-iso88591) and I found a small problem with the test suite (make test calls sanity.sh), in order to have a correct verification on some system messages (like 'No such file or directory' in test ' cvsadm-2d3-1' line 11240) the LANG variable should be set to C on the beginning of the script. The script sets LC_ALL, which the Single UNIX Specification says is supposed to override LANG. I'd say your old HP-UX system is defective. -Larry Jones The problem with the future is that it keeps turning into the present. -- Hobbes ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: MODIFIED: src ...
HDerek Robert Price writes: Is it the test that's failing or the CVS code? I didn't save the output from the failure case. The test. I'm in the process of revising it along the lines I suggested to avoid it failing again until 2096. -Larry Jones ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: MODIFIED: src ...
Derek Robert Price writes:
dotest rcs2-7 ${testcvs} -q update -p -D '100 months' file1 head
revision
Which seems to assume that eight years and four months from now (100
months) is later than 2004.08.31.01.01.01to get the head revision
result. The archive file doesn't appear to be dynamically generated but
rather a static here-doc. Therefore, doesn't any output other than
head revision mean that the checkout command itself is failing?
Yes, the checkout command is failing, but that's because the test is
deficient, not CVS. I suppose it's a matter of perspective: If you
naively add 100 months to October 31, 2002, you get February 31, 2011,
which is an invalid date. That's what currently happens, so you get an
error that the specified date is invalid (Can't parse date/time). A
more sophisticated addition could be used to come up with a valid date,
but which one? One could make a good argument for either March 1 or
March 3, but either one is apt to be surprising to some people. Since
there's no single, obviously correct answer, I think producing an error
is the right thing to do.
-Larry Jones
Hmm... That might not be politic. -- Calvin
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS update: MODIFIED: src ...
Derek Robert Price writes: You could argue for February 28th (or 29th in a leap year), for that matter. End of October + 100 months = end of February. Indeed. What about setting errno in getdate.y and setting a string to the unparsable date or more likely setting a global error string to a complete error message including the invalid date. I think Date/time resolves to non-existant date: Feb. 30, 2004 is much more user-friendly than Can't parse date/time: 100 months, which is almost the same error message I'd get if I asked CVS to parse asdfkhjgfadlhglfj as a date. I'm not sure it's worth it, I don't recall anyone ever being confused by an unparsable date/time (other than ones caused by Y2K bugs). Note that getdate() is, at least in theory, a common (shared) library routine -- I believe the version we have was lifted from GNU tar -- so we may not want to change it, although I believe the current implementation (at least what's in glibc) has deviated quite substantially from the historical implementation. The Single Unix Specification requires a templatized version that doesn't seem to accept relative times at all. There are some relevant comments in the texinfo source for the CVS manual in the description of the -D option starting around line 7960 that are worth reading. -Larry Jones I'm crying because out there he's gone, but he's not gone inside me. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 rdiff fails with binary files
[EMAIL PROTECTED] writes: Shouldn't rdiff act like diff, and just print out that the binary files differ? No, cvs *diff* should work just like diff, and as far as I know, it does. cvs *patch* (aka rdiff) is specifically intended for making patches and thus is much more restrictive and less flexible. What exactly is the point of the cvswrappers option during import (-W)... it doesn't seem to matter with rdiff. Is this just an rdiff quirk, or am I missing something? It marks the file as binary, which affects many things -- including rdiff -- just not in the way you wanted. -Larry Jones Mr. Subtlety drives home another point. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs commit abends
Richard Philley writes: I believe I've hit a bug in CVS 1.11.2 I am running on Solaris 2.6, 7 8, CVS compiled with gcc-3.0.1 I believe it's fixed in the current development version. You may want to try it out and let us know whether it still occurs or not. The repository is accessed via the local method on an NFS mount. That's a bad idea -- search the archives for NFS if you don't already know why. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Right to privacy client info strings
Derek Robert Price writes: I'm also talking about some pretty simple information. Client name version perhaps. Platform I can see as invasion of privacy. As near as I know, all the web browsers send a client name and version as part of the HTTP protocol. I haven't heard any objections to that. Most browsers also include the platform. For example, my version of Netscape sets User Agent to: Mozilla/4.7 [en] (X11; U; BSD/OS 4.0.1 i386) And IE: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) There appears to be on-going discussion of exactly how much platform information should be provided and whether it should be for the compilation platform or the run-time platform. See: http://www.mozilla.org/build/revised-user-agent-strings.html -Larry Jones Your bangs do a good job of covering up the lobotomy stitches. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: History files - cvs administration
Brusset, Mathieu writes: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C27C65.EB60DC90 Please do not send MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! How could I get information about each field of this history file? Is it possible to add more information in it ?? The format is documentated in the source code: src/history.c. The only way to add more information is by modifying CVS. My goal is to be able to answer question as: What tags are in my repository ? Who have done what ? Which files are contained in a given tag ? And stuff like this ... The history file does not answer those questions. -Larry Jones I hate it when they look at me that way. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Mark D. Baushke writes: Larry Jones [EMAIL PROTECTED] writes: In either case, I believe the loop is a separate problem that I checked in a fix for back on 2002-10-04. Hmmm... was that the change to server.c server_cleanup and server or something else? That's the one -- there were changes in client.c, main.c, and server.c that all go together. -Larry Jones Honey, are we out of aspirin again? -- Calvin's Dad ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Problem with cvs 1.11.2 and tracking third-party sources
Stefan Scherer writes: prompt cvs checkout -jGS_7_03 -jGS_7_31 test cvs checkout: Updating test U test/gs_setpd.ps cvs checkout: nonmergeable file needs merge cvs checkout: revision 1.1.1.8 from repository is now in test/gs_setpd.ps cvs checkout: file from working directory is now in .#gs_setpd.ps.1.4 C test/gs_setpd.ps CVS is telling you that it was unable to merge the file automatically, so you're going to have to do it by hand. (Why do you have PostScript files marked as unmergable in your wrappers file? PostScript is generally text that merges quite well.) The strange thing is, cvs showed me a C state, but looking with cvs -n -q update to the source tree, the file has only M state and can be commited. That may be regarded as unfortunate. That's what I always do. This examples shows only one file, the normal source tree has some hundred files and you can't have a look to all lines in the stdout. I always check only afterwards with cvs -n -q update and work through all files with a C state. Bad idea -- you really do need to look at all the output. You can always save it in a log file. Ok, I've commited the merge results and now our changes have gone in the main branch. The following diff shows no differences between main branch and vendor branch. Of course -- CVS *told* you it couldn't do the merge and was replacing your working copy with the repository copy and you went and committed it without doing a manual merge. You got exactly what you asked for. -Larry Jones Why can't I ever build character in a Miami condo or a casino somewhere? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: LinCVS under win and license problem
Derek Robert Price writes: Anyone know if there is any significance to the copy of the GNU LGPL distributed in the COPYING.LIB file in the top level of the CVS source distribution? The few source files I peeked at all specify the General Public License. Some of the files in lib specify the LGPL. -Larry Jones Nobody knows how to pamper like a Mom. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Unicode support for CVS
Da Costa Martins, Iolanda Maria writes: Should I conclude that my UTF-16 files (not the UTF-8, I know that) have to be binaries in CVS or could I seek for a positive answer on: yes, they can be handled as text. And then where is the problem lying when CVS complains about my commit as text, stating that these files should be commited as binaries? If you're using a platform that does not distinguish between text and binary files (Windows does, most Unix-like systems do not), then you can handle *any* file as text. If your platform does distinguish, then you must mark UTF-16 files as binary or risk corruption due to line-ending conversions and, perhaps, incorrect end-of-file detection. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs get -d some/dir in pserver mode doesn't work right if some/dir has '/' in name
Dmitriy Beloslyudtsev writes: Synopsis:cvs get -d some/dir in pserver mode doesn't work right if some/dir has '/' in name [...] cd /var/tmp mkdir ncbi cvs get -d ncbi/demo distrib/demo A long-standing (and very hard to fix) bug. The workaround is to just cd to the parent of the directory you want checked out: cd /var/tmp mkdir ncbi cd ncbi cvs get -d demo distrib/demo -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: (no subject)
[EMAIL PROTECTED] writes: If I use any of the other versions of cvs that I have on my pc (1.10.5 or 1.11) all is fine. When I switch to v1.11.2, I get the following message when I do cvs co -c, and it just hangs: ' from cvs serverckout: warning: unrecognized response `ok Your rsh command is doing line-ending conversions, which screws up the CVS client/server protocol. Use the :server: connection method instead of :ext:. -Larry Jones Nobody knows how to pamper like a Mom. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Infinite loop in cvs server
Pavel Roskin writes: I run cvs server from the command line (I tried Linux console and rxvt - same result), then I press Ctrl-C and Ctrl-D. This message is printed continuously: cvs: buffer.c:1384: stdio_buffer_shutdown: Assertion `fstat ( fileno (bc-fp), s ) != -1' failed. I can only kill cvs by the KILL signal. That's been reported before -- it's a bug in the cleanup code that results in an infinite loop (the assertion failure in the cleanup code results in the cleanup code being called again ad infinitum). I cannot reproduce this bug over ssh (OpenSSH_3.4p1) - cvs terminates on Ctrl-C. However, I cannot exclude the possibility that this bug can be exploited to execute random commands on a server that only allows the user to execute cvs server. It's a simple infinite loop, not a buffer overflow or anything else exploitable. -Larry Jones I obey the letter of the law, if not the spirit. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Infinite loop in cvs server
Pavel Roskin writes: I run cvs server from the command line (I tried Linux console and rxvt - same result), then I press Ctrl-C and Ctrl-D. This message is printed continuously: cvs: buffer.c:1384: stdio_buffer_shutdown: Assertion `fstat ( fileno (bc-fp), s ) != -1' failed. I can only kill cvs by the KILL signal. That's been reported before. There's a bug in the cleanup code that causes it to go into an infinite loop: the assertion failure ends up calling the cleanup code which causes the assertion failure again. I've checked in a fix. I cannot reproduce this bug over ssh (OpenSSH_3.4p1) - cvs terminates on Ctrl-C. However, I cannot exclude the possibility that this bug can be exploited to execute random commands on a server that only allows the user to execute cvs server. It's a simple infinite loop, not a buffer overflow or anything that's exploitable. -Larry Jones You're just trying to get RID of me, aren't you? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs add -m in client/server
Dimitrie O. Paun writes: It looks like cvs add -m drops the file description when working in client/server mode. Yep, it's listed in the BUGS file. Ir is important that I get this feature working again, but before I start hacking away, I would like to ask a few questions of the ones in the know: 1. Has this been fixed already? 2. Is there a patch floating around? 3. How hard would it be to fix it? 4. What would it entail? (incompatible protocol, etc.) 5. Where should I start? As far as I know, no one has ever considered this important enough to even start looking into it. The workaround is to use cvs admin -t to set the message after committing the file for the first time. If you're determined to fix it, it's going to be a bit tricky. Here's the scoop: Nothing happens in the repository when you add a file; the repository isn't updated until you commit it. If there's a descriptive message, it's stored in a ,t file in the CVS subdirectory of the current working directory. When you commit the file, CVS looks for the CVS/file,t file and uses it for the message. This all works fine in local mode. The problem comes in client/server mode. When you do the add, it's the *server* that creates the ,t file, not the client. Unfortunately, nothing ever happens to the ,t file on the server and it's deleted when the server cleans up its temp directory at the end of the command. To fix this, you'll have to figure out a way to get the client to remember the add message (you could still use the ,t file) and then send it to the server when the file is committed. Unfortunately, there's nothing in the current client/server protocol to do that; you'll either need to extend the protocol (ensuring that it remains backward compatible so that old clients still work with new servers and new clients still work with old servers) or kludge something up like sending an add command for each new file with a message in addition to the commit (and note that the existing client always sends just a single command, so multiple commands may not actually work correctly in the server). -Larry Jones Philistines. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS LOGIN ERROR
Ibrahim Shaik writes: I checked the syslog , for messages from inetd.conf particularly for CVS , You want to check for messages from CVS itself, not inetd. Why is it giving this error. And why does winCVS or any other client show the error as cvs login cvs [login aborted]: authorization failed: server 66.125.19.74 rejected access to /usr/local/cvsrepository for user cvsusergroup. When this happens, the server should log a message under the DAEMON facility that says either login refused for repository (which indicates that the specified repository isn't valid) or login failure (for repository) (which indicates that either the username or passwordisn't valid). In the later case, if your system has an AUTHPRIV facility, it will also log a message there containing the username and password. Since it looks like the specified repository exactly matches the --allow-root= option in inetd.conf, I'd say either the username or password isn't right: are you using a $CVSROOT/CVSROOT/passwd file or system authorization? -Larry Jones I'm crying because out there he's gone, but he's not gone inside me. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS LOGIN ERROR
Ibrahim Shaik writes: I had tried both the options , I added a user ( group called cvsusergroup) and added few existing Unix users (myself,sysadmin ) to this group. I defined cvsusergroup user's home directory as cvsrepository. Also made that user as owner of that group. Gave --rwe-- permissions to the repository. Try su'ing to cvsusergroup and running CVS in local mode to be sure that works; do something innocuous like checking out CVSROOT. That way you'll know the permisions aren't screwing things up. I also have a CVS admin GUI page from where I can add cvs users. I added few cvs users and defined them to access the files as cvsusergroup ... This added the following lines to $CVSROOT/cvsroort/passwd file Ibrahim:password:cvsusergroup cvsusergroup:password:cvsusergroup. Those are encrypted passwords, not plain text passwords, right? I am really going crazy with this error. What is the cvspserver/tcp: bind: Address already in use error? Note that that's a inetd message and has nothing to do with your login problem. Most likely it means that you restated inetd very shortly after killing it so that the system still had the existing sockets around to handle any late packets from remote systems. Since inetd seems to be working fine, it must have dealt with the errors appropriately. How do we define cvspserver to authenticate the users againt the users in the passwd file or against the system users? That's SystemAuth in the $CVSROOT/CVSROOT/config file -- it defaults to yes, which means CVS uses both the system passwd file and its own passwd file. -Larry Jones I think if Santa is going to judge my behavior over the last year, I ought to be entitled to legal representation. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Derek Robert Price writes: Can you suggest an alternative to get around the blocking problem? It looks to me like we're just screwed. The problem is that when old clients use compression, they don't actually close the connection to the server until after the server closes its connection to them. The old server didn't check for EOF on the input stream before closing it, so it didn't matter, but the new server does and thus hangs. I think our best course of action is to just remove the EOF check from the input buffer case in stdio_buffer_shutdown(), which was the originally suggested fix. I don't like it, the old client behavior is clearly wrong, but I think it's the lesser of two evils. By the way, it looks to me like the two if (server_active)s in that code should actually be if (!server_active)s, no? -Larry Jones I don't see why some people even HAVE cars. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs 1.11.2 buffer.c blocking socket/pipe w/bugfix
Derek Robert Price writes: Hmm. You're right. All the getc() call really seems to be checking for is EOF - I was thinking the attempt to get a character was important for some reason. Anyhow, I'm running a make check on it now. If it's successful and there are no objections raised, I'll check it in. I assume you're checking: Mark D. Baushke wrote: Hmmm.. I have not tested it, but I suppose !feof(bc-fp) might work on some platforms. If so, it most definitely is *not* equivalent and does not work on any platform. feof() doesn't return true unless some actual I/O routine has already encountered EOF, which won't ever have happened in normal operation. The call to getc() is an actual I/O that tests for EOF now. -Larry Jones Nothing spoils fun like finding out it builds character. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: More on 1.11.2 corruption problem
Axel Bodemer writes: a local diff give a correct result. But over the net, with pserver, cvs give no result. CVS meen, there are no differents. You need to provide more details about exactly what you did, the results you got, and the results you were expecting. -Larry Jones The game's called on account of sudden death. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: rtag -a bug
Hackett, Jonny E writes: rtag -a tagname module The above command will add the tagname to the head revision of files where that tag doesn't exist. Yes, it will, provided those files are not in the Attic. It will also *remove* the tag from any files in the Attic where it does exist. According to the cvs documentation, this command should only remove the specified tag from files in the Attic. Is the documentation incorrect? Or is this a valid bug. The documentation is perhaps too terse. The functionality may leave something to be desired, too. Here's what it really does: If you use -a and don't use either -r or -D, the tag is removed from any files that are in the Attic and added to the most recent revision of any files that are not in the Attic. If you use -a along with -r or -D (or both), the tag is added to any files (whether in the Attic or not) that have a matching revision and removed from any files (whether in the Attic or not) that don't. -Larry Jones Apparently I was misinformed. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: 1.11.2 problem
Mike Quinn writes: When using 1.11.2 and adding a new branch tag - the database becomes corrupt. This does not happen with 1.11. If there's any more info I can supply, short of the actual databases, please let me know. Exactly what you did, the exact errors you got, and your configuration (is the repository local, network mounted, or are you using client/ server CVS; what platform(s); anything other than comments in CVSROOT/config, etc.) would be a good start. -Larry Jones I won't eat any cereal that doesn't turn the milk purple. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS LOGIN ERROR
Ibrahim Shaik writes: Now the main problem I am facing is , when ever I try to connect using jCVS , it says I HATE YOU . It is not authenticating any user . Check your syslog for the DAEMON facility for messages from CVS. They'll give you more information about what the actual problem is. -Larry Jones Archaeologists have the most mind-numbing job on the planet. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS export bug: CVS subdirectory is created during export ...
Jens Engel writes: Sometimes a CVS subdirectory is created on the first directory level when the exported CVS module has subdirectories. It would be helpful if you could run the offending command with a trace (cvs -t) and post it along with the contents of your module file if it contains a definition for the module you're exporting or a listing of that directory in your repository if it doesn't. -Larry Jones ANY idiot can be famous. I figure I'm more the LEGENDARY type! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: gnu/42726 (Was: cvs checkout bug existing val-tags and readonlyfs)
Eugene Grosbein writes: I've applied this patch, rebuilt cvs and still get: Protocol error: uncounted data discarded. That's a completely different and unrelated problem. It seems to be timing dependent since it's not generally repeatable. In fact, none of the CVS developers has been able to reproduce it in order to track it down. It is, so far as I know, harmless, though disturbing. -Larry Jones I've got an idea for a sit-com called Father Knows Zilch. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: gnu/42726 (Was: cvs checkout bug existing val-tags and readonlyfs)
Eugene Grosbein writes: One more addition: if I run 'cvs --allow-root=/home/ncvs' instead of 'cvs --allow-root=/home/ncvs' I see it still tries to create lock in the repository and fails due to 'Permission denied'. [...] instead of 'cvs -R --allow-root=/home/ncvs'. And your point is? You can use LockDir= in CVSROOT/config to put the lock files somewhere other than in the repository. I have no idea what -R does since that's not in standard CVS. You can also specify the global -n option to CVS in most cases to avoid creating lock files at all. -Larry Jones Don't you hate it when your boogers freeze? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs hang bug with 'make check' cvs-1.11.2 sun spars sunos 5.2
Jeff Deifik writes: The 'make check' hangs at this point. I have waited over 30 minutes. That may not be long enough -- there are a *lot* of tests. The tests write a log file in src/check.log -- as long as that file is getting bigger, the tests are still running. There are some intentional delays of up to one minute during the tests, so don't pull the plug too quickly. If it really is hung, the end of the log file should identify the culprit test. You might also want to use top or ps to see what, if anything, the hung test is doing. -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS hangs on commit (fix against 1.11.2 enclosed)
[EMAIL PROTECTED] writes: Description: When committing and not adding a description, cvs does commit the files but also hangs afterwards, causing a stale lock. That's already fixed in the development version, but thanks anyway! -Larry Jones Ever notice how tense grown-ups get when they're recreating? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: [Fwd: Returned post for dev@ccvs.cvshome.org]
Emanuela Fiucci writes: cvs import -I ! -I CVS -W *.doc -k 'b' -W *.xls -k 'b' -m no message blu avendor arelease (in directory F:\blu) Cannot access /cvs/CVSROOT No such file or directory Can you help me? You need to do cvs init to create the repository before you can import into it. -Larry Jones I don't NEED to compromise my principles, because they don't have the slightest bearing on what happens to me anyway. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: assigning revisions
Daniel Lungu writes [in very long lines]: Concurrent Versions System (CVS) 1.10.7 (client/server) 1.10.7 is very old -- you should consider upgrading. - error: first number in revision of b should be - - highest first number of any file in that directory - $ cvs commit b RCS file: /cvsroot/Soft/module/b,v done Checking in b; /cvsroot/Soft/module/b,v -- b initial revision: 1.1 done That's a subtle difference between local mode and client/server mode. In local mode, the command runs in your actual working directory and does what you expect. In client/server mode, the command actually runs in a shadow directory on the server that contains just the modified files (which in this case is just b). Revision numbers are for CVS's internal use -- you shouldn't try to mess with them or use them for your own purposes: use tags instead. - furthermore: cannot commit changes to a anylonger - [...] $ cvs commit a cvs server: sticky tag `2.0' for file `a' is not a branch cvs [server aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsBAAaaLWoa When you do a commit -r, it sets a sticky tag on the file in your working directory. You need to remove that sticky tag (with update -A) before you can commit any additional changes. -Larry Jones Geez, I gotta have a REASON for everything? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: conflict and .#file
jose writes: I think I found a bug in cvs. Nope. CVS creates a .#file when it finds a conflict in the file, and then No, it create a .#file whenever it merges changes, reguardless of whether there are conflicts or not. -Larry Jones You're going to be pretty lonely in the nursing home. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: v1.11.2, cvs admin substitution settings change issue
Ronald Wertlen writes: cvs add -ko ControllerProcessors.doc cvs ci -m ControllerProcessors.doc done cvs status ControllerProcessors.doc Sticky Options: -ko cvs admin -kb ControllerProcessors.doc done cvs status ControllerProcessors.doc Sticky Options: -ko the cvs admin command (version is 1.11.2) falsely reports the substitution settings change as done. No, admin has successfully changed the substitution settings *IN THE REPOSITORY*. You can use cvs log to see that. What you're looking at is the sticky options *in your working directory*. Use cvs update -A to update your working directory options to match the repository. -Larry Jones Apparently I was misinformed. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Is this a bug ?
[EMAIL PROTECTED] writes: MIME-Version: 1.0 Please do not post MIME and/or HTML encrypted messages to the list. Plain text only, PLEASE! This happens because the file Entries in the directory rootdir/workdir/datadir/CVS still contains the line D/datadir. I would have thought that the command cvs release -d datadir would have cleared this line from the Entries-file. My questions are : Is it normal that this line is not cleared ? Yes. I consider this a bug, but have not gotten around to fixing it. Is it normal that the cvs status command aborts when it doesn't find a directory corresponding to the Entries-file ? Also yes. This is not a bug. -Larry Jones Ha! Wild zontars couldn't drag that information out of me! Do your worst! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs log -rtag_at_base_of_branch::tag_on_branch fails
[EMAIL PROTECTED] writes: % cvs log -N -rv1_0::v1_1 foo cvs server: invalid branch or revision pair v1_0:v1_1 in `/pgrd/ljdev/cvsroot/TE STME/foo,v' Upgrade your server to CVS 1.11.2. For future reference, cvs version will give you both the client and server version numbers. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs log times
Jean-Pierre Sevigny writes: I am not getting the right dates for my logs, i am getting GMT time. Those are the right dates -- CVS always displays times in UTC. Displaying times in local time is certainly possible, but it's a bit tricky (particularly in client/server mode) and requires some enhancements to the client/server protocol which no one has gotten around to doing. -Larry Jones I think grown-ups just ACT like they know what they're doing. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs import: cannot lstat file : No such file or directory
[EMAIL PROTECTED] writes: Does anyone know what might cause CVS to cut off the first half of all of my files when I try an import? I'm running this on a Solaris 8 machine. That looks like the kind of weirdness you get when you mix and match the regular and BSD-compatible libraries. Did you build CVS yourself? If so, make sure you don't have /usr/ucb in your path when you run configure and make. You should use make distclean to start over, then run configure and make. If you still have the same problem, post the output from running configure. -Larry Jones What better way to spend one's freedom than eating chocolate cereal and watching cartoons! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs import: cannot lstat file : No such file or directory
[EMAIL PROTECTED] writes: So I ran: CC=/usr/ucb/cc ./configure -prefix=/app/cvs NO! Do *NOT* use the UCB C compiler -- that's your problem. You need to find the real C compiler and add it to your $PATH. Most likely, you need /opt/SUNWspro/bin and /usr/ccs/bin. -Larry Jones It's clear I'll never have a career in sports until I learn to suppress my survival instinct. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs-1.11.2 make check failure
Paul Jarc writes: My touch command is from GNU fileutils 4.1.8. How can I investigate what's going wrong with tag8k-17? Read TESTS for guidance. I also had a failure with history-1; the test seems to assume that the system clock uses the UTC timescale; mine uses the TAI timescale, which is like UTC but includes leap seconds. I worked around this by setting TZ=UTC in the environment (the TAI time zones are right/*). It would be nice if the test did this itself, or if the assumption were removed somehow. Hmmm. CVS uses gmtime(), which should not be affected by the timezone, but on your system it apparently is. Since you've chosen to break your system (TAI is right for many things, but the system clock is not one of them), I think you just need to deal with it yourself. -Larry Jones What better way to spend one's freedom than eating chocolate cereal and watching cartoons! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs-1.11.2 make check failure: rsh
Paul Jarc writes: I would be nice if this were considered nonfatal: ERROR: cannot test remote CVS, because `rsh multivac.cwru.edu' fails. If some external dependency is not satisfied, I'd like to be able to run just whatever tests are possible, and have sanity.sh exit 0 if those succeed. No part of CVS is known to have failed here. make check runs sanity.sh twice: once in local mode, and once in client/server mode. If rsh doesn't work, then essentially all of the tests fail (in client/server mode), and sanity.sh indicates that with its exit status. If you don't want to run the tests in client/server mode, use make localcheck instead (likewise, you can run just the client/server mode tests by using make remotecheck). -Larry Jones In a minute, you and I are going to settle this out of doors. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: FW: cvs diff different to rcs diff
[EMAIL PROTECTED] writes: Can diff be modified: 1) to allow an rcs-like diff option (I can see the benefits of having both styles available) and cvs diff -rHEAD -Larry Jones I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Error encountered in commit operation
Nidhi Rustagi writes: Command : cvs ci decoder/ The trailing slash confuses CVS. You should just do: cvs ci decoder Usually, one is already *in* the working directory, so a simple: cvs ci suffices. -Larry Jones He piqued my curiosity. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: (no subject)
Rodney Kadura writes: Release: cvs-1.9 [...] Description: -D option does not accept any date for year 2000 or later. Please upgrade -- the current release of CVS is 1.11.2. You can find it at www.cvshome.org. -Larry Jones Monopoly is more fun when you make your own Chance cards. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: cvs diff -r HEAD doesn't show differences
Stephen Rasku writes: When I do cvs diff -r HEAD from a branch it doesn't show any differences even though the HEAD and the branch are different: I think diff interprets HEAD as the head of the branch, not the head of the trunk. -Larry Jones It must be sad being a species with so little imagination. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: bug: files not in working dir after checkout
Jan Ohlhorst writes: if i do a checkout of a dir which already exists in my working-dir before the checkout, the files (of the repository) which belong to that dir are not copied to my working-dir. I can't seem to reproduce that problem with the current version of CVS (1.11.2). -Larry Jones It works on the same principle as electroshock therapy. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sticky date on a branch
Veda Larson Palmer writes: cvs co -r myBranchTag -D myDate myFile then run cvs status on the file, it says Status: Needs Patch and Sticky Date: (none) (although the sticky tag is correctly set to the branch tag). Am I doing something wrong or is this a bug? It's more of a limitation than a bug -- CVS was designed to have a sticky tag or a sticky date, but not both. -Larry Jones Do you think God lets you plea bargain? -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: (no subject)
[EMAIL PROTECTED] writes: on login failures, lines like the following appear in the syslog: cvs: login failure by tom / °^F^W@°^F^W@^P (for /home/cvs) it should be obvious that the part behind the / is not any actual data, so it most likely is grabbing into a wrong memory area there. if the data that should be there is remotely-supplied (password? servername?) it may be possible to exploit this. It's the right memory area, but it's already been free'ed. I can't imagine any way to exploit it. It's fixed (over a year ago) in CVS 1.11.2, which you can get from www.cvshome.org. -Larry Jones These pictures will remind us of more than we want to remember. -- Calvin's Mom ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: BADROOT
Anthony Shipman writes: It seems the only purpose of the restriction is to prevent the user name in the log message being root. Exactly. Since root is usually a shared account, if the log message just says root you won't know which real person made the changes. But in subr.c the getcaller() function will read LOGNAME or USER which I can set to control the name in the log file, if I care. getcaller() only reads $LOGNAME or $USER if getlogin() fails, which it shouldn't ever do, provided you've actually logged in at some point. So how about getting rid of this restriction? As root, I would like to maintain system configuration files/logs with cvs. If you want to allow root to commit, just don't define CVS_BADROOT in options.h. -Larry Jones I won't eat any cereal that doesn't turn the milk purple. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: PROPOSAL: Add --disable-setuid to configure to disable calls to setuid(), etc.
James E Jurach Jr. writes: PURPOSE: To allow pserver to run as non-root. It already can, you just need to use the third field in CVSROOT/passwd file to map every CVS user to the system user you're running pserver as. -Larry Jones Everybody's a slave to routine. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Bug in CVS
Sukesh 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 log command does not work recursively. I mean it is not able to = generate log files at one shot to all the files if the files are = recursive. Yes it does. You either have -l specified in your ~/.cvsrc or you're doing something wrong. If you can't figure it out, you need to show us an example. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: CVS watch command
Herb Croken writes:
I am trying to set a watch on a file and when I enter CVS watch on
filename I get the message unknown Command watch_on, where watch anf on
are concatenated with an underscore. Ideas??
That's a known bug in CVS 1.11.2 that's already been fixed in the
current development version. Either run the current development version
or apply the following patch:
Index: server.c
===
RCS file: /cvs/ccvs/src/server.c,v
retrieving revision 1.273
retrieving revision 1.274
diff -u -r1.273 -r1.274
--- server.c11 Feb 2002 18:49:33 - 1.273
+++ server.c3 May 2002 17:20:48 - 1.274
@@ -3712,7 +3712,7 @@
serve_watch_on (arg)
char *arg;
{
-do_cvs_command (watch_on, watch_on);
+do_cvs_command (watch, watch_on);
}
static void serve_watch_off PROTO ((char *));
@@ -3721,7 +3721,7 @@
serve_watch_off (arg)
char *arg;
{
-do_cvs_command (watch_off, watch_off);
+do_cvs_command (watch, watch_off);
}
static void serve_watch_add PROTO ((char *));
@@ -3730,7 +3730,7 @@
serve_watch_add (arg)
char *arg;
{
-do_cvs_command (watch_add, watch_add);
+do_cvs_command (watch, watch_add);
}
static void serve_watch_remove PROTO ((char *));
@@ -3739,7 +3739,7 @@
serve_watch_remove (arg)
char *arg;
{
-do_cvs_command (watch_remove, watch_remove);
+do_cvs_command (watch, watch_remove);
}
static void serve_watchers PROTO ((char *));
-Larry Jones
You're just trying to get RID of me, aren't you? -- Calvin
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Bug on TAGs
patrick.nomblot writes: I have found a bug (I suppose it is) on TAG wich becomes a branch. A TAG name with a - becomes a branch when used in the repository root : The tag name doesn't have to contain a -, any name will work the same. Nor does it only happen in the root directory, any directory with no files behaves the same way. The problem is that a tag has no life of its own -- it only exists inside each individual RCS file. A tag can be a branch tag in one RCS file and a revision tag in another. So, there's no way for CVS to know in isolation whether a tag is intended to be a branch tag or a revision tag. What update does is to assume that the tag is a branch tag unless there's at least one RCS file in the directory where it's a revision tag. If there are no files in a directory, then the initial assumption is never contradicted. This simply can't be made to work right without completely redesigning CVS. My feeling is that the current behavior is the lesser of two evils. -Larry Jones Life's a lot more fun when you're not responsible for your actions. -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs script not correct
Matthew Fleming writes [in one long line]: The sccs2rcs script is not correct: This is the version that I created to address the problems.. the changes are to the first line and the first set date line needed to be added. You have an old version -- the current version works fine. Your version, on the other hand, is buggy: * The first line needs a space between the #! and the /bin/csh to be portable. * Line 72 is missing its closing quote. -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
