Re: cvs abusing stderr?
but I am sure that it can read from cvs' stdout instead of stderr, too. Yes, it *could*. But at the moment it expects this particular input from stderr and all (?) other versions of CVS servers send it at stderr. There are already too much differences between GNU CVS and CVSNT... Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? It would be more consistent, if the client-server protocol (and this is what we are talking about) would send the information in a unambiguous format and translate it *at client side* in human readable text. Unfortunately, the CVS server already converts it to human readable format and the more advanced clients need to parse it, which is not possible correctly in all cases (e.g. imagine file names with spaces and the output of the 'cvs history' command). -- Best regards Thomas Singer _ smartcvs.com Harald Dunkel wrote: [EMAIL PROTECTED] wrote: Just to prevent an out-of-the-brain change: if they would we sent to stdout, this would break at least SmartCVS. I don't want to break your GUI, but I am sure that it can read from cvs' stdout instead of stderr, too. Wouldn't it be more consistent to reserve stderr for error messages, and to write log messages to stdout, as usual? Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: cvs abusing stderr?
Just to prevent an out-of-the-brain change: if they would we sent to stdout, this would break at least SmartCVS. -- Best regards, Thomas Singer _ smartcvs.com Harald Dunkel schrieb: Jim.Hyslop wrote: I can't comment on why these messages go to stderr instead of stdout, but I will mention that the global -q flag suppresses them. I use '-q' so much it's in my .cvsrc file ;-) I have seen -q and -Q, but I don't want to suppress these messages completely. They should just not go to stderr. Regards Harri ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: editors get lost with running an update
Using the diff command is no option, because it uses E responses instead of sending the file content. This causes major troubles with non-ASCII-characters. -- Best regards, Thomas Singer _ smartcvs.com Jim.Hyslop schrieb: Thomas Singer wrote: We've encountered a problem with GNU CVS 1.12.9. Please see the following log. [...] CVSNT 2.0.58d behaves correctly, it keeps the editors information. What request SmartCVS should send, so GNU CVS 1.12.9 just sends the original content of the file without destroying the editors information? Thanks in advance. Well, I think the first thing to do is to fix the bug (sounds like a bug in CVS 1.12 to me). I don't have a copy of 1.12 handy to test this, but try adding the -p option to see if that helps. Since you're doing a file compare, you could just do it the way CVS expects you to - invoke the 'diff' command and send the current contents of the file ;=) Or, since you want to fetch the original version in its entirety, you could send an empty file. CVS will then respond with all the lines that you deleted, i.e. the entire file (which you can then redirect to your external file comparer). ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Unexpected directory-entry in CVS/Entries
Hi, I have a simple project in the repository: [repository-root] + test/ + sub1/ | + test1.txt + sub2/ + test2.txt Now I check out test/sub1 and test/sub2 nested in each other: [EMAIL PROTECTED]:~$ mkdir cvstest [EMAIL PROTECTED]:~$ cd cvstest [EMAIL PROTECTED]:~/cvstest$ cvs-1.12.11 -d :local:/misc/repository checkout -d sub1 test/sub1 cvs-1.12.11 checkout: Updating sub1 U sub1/test1.txt [EMAIL PROTECTED]:~/cvstest$ cd sub1 [EMAIL PROTECTED]:~/cvstest/sub1$ ls -al CVS insgesamt 20 drwxr-xr-x2 singer singer 4096 2005-02-23 08:46 . drwxr-xr-x3 singer singer 4096 2005-02-23 08:46 .. -rw-r--r--1 singer singer 47 2005-02-23 08:46 Entries -rw-r--r--1 singer singer 10 2005-02-23 08:46 Repository -rw-r--r--1 singer singer 24 2005-02-23 08:46 Root [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries /test1.txt/1.1/Tue Feb 22 18:39:14 2005/-ko/ D [EMAIL PROTECTED]:~/cvstest/sub1$ cvs-1.12.11 -d :local:/misc/repository checkout -d sub2 test/sub2 cvs-1.12.11 checkout: Updating sub2 U sub2/test2.txt [EMAIL PROTECTED]:~/cvstest/sub1$ ls -al CVS insgesamt 24 drwxr-xr-x2 singer singer 4096 2005-02-23 08:47 . drwxr-xr-x4 singer singer 4096 2005-02-23 08:47 .. -rw-r--r--1 singer singer 47 2005-02-23 08:46 Entries -rw-r--r--1 singer singer 13 2005-02-23 08:47 Entries.Log -rw-r--r--1 singer singer 10 2005-02-23 08:46 Repository -rw-r--r--1 singer singer 24 2005-02-23 08:46 Root [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries /test1.txt/1.1/Tue Feb 22 18:39:14 2005/-ko/ D [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries.Log A D/sub2 [EMAIL PROTECTED]:~/cvstest/sub1$ As you can see, for some mysterious reason, CVS 1.12.11 creates an entry for sub2 in the parent's CVS/Entries(.Log). This also happens when the second checkout comes from a different repository. When both checkouts come from the same repository, a cvs update sub2/test2.txt works, but it fails when both come from a different repository. What do you think about it? Is this correct behaviour to link independent working copied together using the entry? Shouldn't the entries and the CVS/Repository content form a valid hierarchy as well as the file system outside of the CVS-directories? -- Best regards, Thomas Singer _ smartcvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
Hi Larry, Thanks for the response. No mystery, just a bit of overloading. In addition to the list of CVS-controlled files, the Entries file also contains a list of the known subdirectories of the current directory (to avoid having to scan the entire directory for subdirectories every time). But in this particular described usecase it is not appropriate, because the subdirectory (here sub2) does not contain to the cvs project of sub1. Could you be a bit more specific about how it fails? Local working copy structure: 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. 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. Not very consistent. I would expect following: 1. Checking out sub2 does NOT create an sub2-entry in CVS/Entries, because it does not belong to the parent CVS file structure. 2. Invoking 'cvs update' in sub1 does not dive into sub2 for both described situations. 3) Invoking 'cvs update sub2/file2.txt' does not work for both situations. When I need to update file2.txt, I first need to switch to this directory. -- Best regards Thomas Singer _ smartcvs.com Larry Jones wrote: [EMAIL PROTECTED] writes: As you can see, for some mysterious reason, CVS 1.12.11 creates an entry for sub2 in the parent's CVS/Entries(.Log). No mystery, just a bit of overloading. In addition to the list of CVS-controlled files, the Entries file also contains a list of the known subdirectories of the current directory (to avoid having to scan the entire directory for subdirectories every time). When both checkouts come from the same repository, a cvs update sub2/test2.txt works, but it fails when both come from a different repository. Could you be a bit more specific about how it fails? -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: Unexpected directory-entry in CVS/Entries
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? Tom [EMAIL PROTECTED] wrote: Hi, I have a simple project in the repository: [repository-root] + test/ + sub1/ | + test1.txt + sub2/ + test2.txt Now I check out test/sub1 and test/sub2 nested in each other: [EMAIL PROTECTED]:~$ mkdir cvstest [EMAIL PROTECTED]:~$ cd cvstest [EMAIL PROTECTED]:~/cvstest$ cvs-1.12.11 -d :local:/misc/repository checkout -d sub1 test/sub1 cvs-1.12.11 checkout: Updating sub1 U sub1/test1.txt [EMAIL PROTECTED]:~/cvstest$ cd sub1 [EMAIL PROTECTED]:~/cvstest/sub1$ ls -al CVS insgesamt 20 drwxr-xr-x2 singer singer 4096 2005-02-23 08:46 . drwxr-xr-x3 singer singer 4096 2005-02-23 08:46 .. -rw-r--r--1 singer singer 47 2005-02-23 08:46 Entries -rw-r--r--1 singer singer 10 2005-02-23 08:46 Repository -rw-r--r--1 singer singer 24 2005-02-23 08:46 Root [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries /test1.txt/1.1/Tue Feb 22 18:39:14 2005/-ko/ D [EMAIL PROTECTED]:~/cvstest/sub1$ cvs-1.12.11 -d :local:/misc/repository checkout -d sub2 test/sub2 cvs-1.12.11 checkout: Updating sub2 U sub2/test2.txt [EMAIL PROTECTED]:~/cvstest/sub1$ ls -al CVS insgesamt 24 drwxr-xr-x2 singer singer 4096 2005-02-23 08:47 . drwxr-xr-x4 singer singer 4096 2005-02-23 08:47 .. -rw-r--r--1 singer singer 47 2005-02-23 08:46 Entries -rw-r--r--1 singer singer 13 2005-02-23 08:47 Entries.Log -rw-r--r--1 singer singer 10 2005-02-23 08:46 Repository -rw-r--r--1 singer singer 24 2005-02-23 08:46 Root [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries /test1.txt/1.1/Tue Feb 22 18:39:14 2005/-ko/ D [EMAIL PROTECTED]:~/cvstest/sub1$ cat CVS/Entries.Log A D/sub2 [EMAIL PROTECTED]:~/cvstest/sub1$ As you can see, for some mysterious reason, CVS 1.12.11 creates an entry for sub2 in the parent's CVS/Entries(.Log). This also happens when the second checkout comes from a different repository. When both checkouts come from the same repository, a cvs update sub2/test2.txt works, but it fails when both come from a different repository. What do you think about it? Is this correct behaviour to link independent working copied together using the entry? Shouldn't the entries and the CVS/Repository content form a valid hierarchy as well as the file system outside of the CVS-directories? -- Best regards, Thomas Singer _ smartcvs.com ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
Re: Unexpected directory-entry in CVS/Entries
*WHAT* error message?!? 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). -- Cheers, Tom Larry Jones wrote: [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 ___ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs
