Per-directory sticky tags - a possible bug?
Hi, I'm using CVS version 1.10.7 on Windows (not using the client/server model). I have a CVS project that is made of some directory tree, where the topmost directory does not contain any files: root subdir1 subdir2 ... The root directory of the project (root) does not contain any files; all files are located in the sub-directories of root. When I use cvs update -r tag-name in the working directory of root, CVS updates the project to the version indicated by tag-name. In the CVS sub-directory of each working directory, it creates the Tag file which indicates the sticky tag. When tag-name is not a branch tag (i.e., it is not the name of a branch), the CVS/Tag files in the sub-directories of root contain the right thing: Ntag-name. However, the CVS/Tag file in the working directory of root, contains: Ttag-name, as if this is a branch tag. This means that I can (I tried, and it works) add files, modify them and commit them in the working directory of root, while I cannot do so for the sub-directories. Is this a bug in CVS? If not, can you explain to me the idea behind this? One more thing that is somehow related to the above: My group always treats a whole CVS project as a single entity - tags are always applied to whole projects and not to specific files/directories of a project. Given that, is there a way for me to know whether my working copy of a project is set to a branch or not? (not just to a branch tag, but to a tag that belongs to a branch) (Let's say I forgot if I checked-out from a branch or not) Thanks a lot, Shlomo ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Monday, July 9, 2001 at 01:03:36 (-0400), Lenny Foner wrote: ] Subject: cvs [commit aborted]: cannot commit files as 'root' In that time, you've come across as basically a reactionary force, in the original meaning of that term---in other words, just about any change to CVS has launched you on a crusade to preserve the One True Original Implementation, even in the face of lots of people who might rather it behaved otherwise. You're obviously not paying attention to what I'm writing. Please try again. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: The hated $Log$ keyword
[ On Monday, July 9, 2001 at 00:01:01 (-0400), Eric Siegerman wrote: ] Subject: Re: The hated $Log$ keyword and that they contain their markers when they appear in a frozen file. Why is this a problem? I very much prefer it. Suppose, using SCCS or raw RCS, I accidentally edit a file I haven't locked. With RCS, once I've seen the permission denied message, I can: :!co -l foo :w! The SCCS equivalent would inappropriately freeze all my keywords. OK, that's a really dumb thing to do when collaborating with others. But then, I've rarely collaborated using raw RCS, and never with SCCS; by the time I had coworkers who were willing to consider version control at all, I'd discovered CVS :-) Well, with CVS the meaning of frozen file is quite a bit different. In the most basic sense what I'm saying is that -kv should be the default for cvs export. In a pure RCS environment the issue with keyword markers in unlocked files is somewhat more complex. If I'm not mis-remembering the history of this feature part of the original intent was to allow for exactly the scenario you describe above. Another feature of this ability was to allow a new RCS ,v file to be created with initial defaults for various values, such as the revision number (i.e. with ci -k): This option is useful for software distribution. A revision that is sent to several sites should be checked in with the -k option at these sites to preserve the original num- ber, date, author, and state. In practice I don't think this scheme has ever worked very well unless all sites in question had an agreed upon branching plan since you still have to either reserve branch numbers for each site (or invent some tool to do branch renumbering, which is I think what BitKeeper does). Of course in both CVS and RCS the ultimate problem with having the keyword markers in the frozen files is that subsequent checkins/imports to a new repository (without '-k') will clobber the old value. This is why '-kv' should be the default for cvs export, and why large projects using RCS (or those using CVS who haven't learned to use cvs export) have always invented their own project-specific keyword (eg. $NetBSD, $Xconsortium, $XFree86, etc.) (Which reminds me -- someone with commit access really should commit the patches from OpenBSD that implement tag=OpenBSD in CVSROOT/config!) BTW, with plain SCCS the workaround for saving changes to unlocked files is to save only the diff and apply it again to the locked file: sccs diff foo.c foo.diff rm foo.c sccs edit foo.c patch foo.c foo.diff # no patch? use 'diff -e' and 'ed' sccs delget foo.c I don't see how one could even do CVS-style unreserved checkouts layered on top of something which handled its keywords the way SCCS does. Should a checkout give you the values (in which case, the magic-keyword-ness is lost on commit), or the keywords (in which case, why bother with keywords in the first place since they never get substituted)? In order to follow the SCCS style of keyword handling CVS would have to always provide only the un-expanded keywords in working directories (i.e. use co -kk in the case of RCS, or always create the working directory with get -k in the case of SCCS). At least this was the conclusion I came to when I was trying to figure out how to make CVS work as an SCCS front-end. Yes this would significantly reduce the utility of keywords, at least for the way many people use them today. However in many environments such a scheme would be more or less invisble (eg. in emacs with the VC hooks enabled the checked out revision is given in the mode line). One advantage of such a scheme would be that people who wanted to use keywords to tag all their published files would soon learn when and how to use cvs export and they'd be much less likely to accidentally publish something from within a working directory! ;-) I'm trying to think of how one could get this to work. You'd have to do some kludge like: - check out with values only into the user's sandbox (actually, SCCS itself gives you no choice, if I recall, since the only way to get keywords only is get -e, which also acquires a lock) No need to do the lock with SCCS, just use get -k - at commit time, do a merge between: 1. a fresh checkout with values only 2. another fresh checkout with keywords only 3. the sandbox file i.e. diff (1) and (2) and apply the results to (3) as a patch I'm not sure where you're going there. Normally in a working directory you'd only ever see the unexpanded keywords (since a concurrent editing system can't predict which file(s) might be edited). At commit time a CVS-like front-end to SCCS would just do something like: delta file.c# delta normally removes the g-file get -k
Strategy of access
I have briefly searched through this list for some informations about access rigths management, policies etc. but unfortunatelly I got no answer. Can anyone tell me where can I get such informations? Or maybe can give some suggestions: Let me explain current configuration: The main strategy is to control users access to selected projects' subdirectories. I use one repository for all projects. CVS server is installed on Linux and dedicated only to use in intranet so advanced security considerations are not necessary. All subdirectories have set up setgid (I read about problems with it on Linux but actually it works on RedHat 6.2). Each subdirectory which is entry to project have set own group as in this example: permissionsgroup dir drwxrws--- users CVSROOT drwxrws--- project_a project_a drwxrws--- project_b project_b drwxrws--- project_c project_c Each CVS user have unix account on server where CVS is installed and his primary group is 'users' (read-write access to some administrative files in CVSROOT). User that can access given project is added to proper group - then that user can fully operate on this subtree. So user (1) can access or (2) cannot access project in repository. But what about (3) read-only access to project (kind of auditing)? Operating on 'readers' or 'writers' CVS adminitrative files is out of scope - it switches access features per-repository not per-directory. Is there any solution of this problem? I read about setting up repository for each project but it doesn't look elegant :) Best regards, Andrew ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS comments
Hi!, I'm trying to get out of CVS the comments put in(or not!!) by my developers, when they commit a module into CVS. I have looked at the history command and the log command, but can't see how this is achieved. Is it possible to extract the comments submitted by a commit? Thanks Steve PlattConfiguration ManagerRDF Consulting01273 20015007808 077538
Re: CVS comments
Hi Steve, I'm trying to get out of CVS the comments put in(or not!!) by my developers, when they commit a module into CVS. I have looked at the history command and the log command, but can't see how this is achieved. Is it possible to extract the comments submitted by a commit? Yes, you can use verifymsg to check the comments e.g. if they are conform to a policy or you can use loginfo to put the messages e.g. into a database or send them by e-mail to other people. Kind Regards. -- Dipl.-Ing. Karl Heinz Marbaise | Phone: +49 (241) 4 13 26 - 48 QIS Systemhaus GmbH Aachen | Fax : +49 (241) 4 13 26 - 40 Juelicher Strasse 338 | Internet: http://www.qis-systemhaus.de 52070 Aachen | e-mail : [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
hiding CVS directory
Hi, Is there any way to rename the CVS directory? Perhaps it would be more appropriately named .CVS Regards, Roger ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: hiding CVS directory
Roger Keays wrote: Hi, Is there any way to rename the CVS directory? Perhaps it would be more appropriately named .CVS Regards, Roger Not w/o changing the cvs code. Why do you need it hidden? -Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
You know.. something I've noticed... On one side there are the people who will never read the manual, but will expect the mailing list, forums, et. al. to answer every little question they have whether it's I can't get my webserver to run cgi scripts or how do I import a new project or I don't understand my algebra homework. On the other side... the manual just plain sucks. It's confusing, poorly organized, badly written, and as you pointed out.. it's sorely lacking a full list of error messages. In short.. it needs to be rewritten very badly. I have a hard time being upset at someone who doesn't RTFM the cvs manual because it's painful to read. Daniel ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Attention CVS Zealots (was Re: cvs [commit aborted]: cannot commit files as 'root')
[EMAIL PROTECTED] wrote: cowed by the thought of having Greg yell at them for days that they're unwilling to start, or if I'm told that no such patch will be accepted to CVS, then it will die here. I generally ignore rants, especially from Mr. Greg Woods. Greg - you're obviously very smart, and very well-informed about CVS, networking and general computing - but STFU already. You have become NOISE. Are you this boorish off-line? I want to see CVS improve and will gladly host / administer any such efforts. In fact, I have planned to do so for quite some time in the context of my plans for freepository. Anyone who desires to improve CVS - behavior, error messages, user interface, bells, whistles or documentation - please reply directly to me off this list. I have the time, desire, knowledge, hardware, and network infrastructure to make this happen. Bullies and weasels Need Not Apply. -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Greg A. Woods writes: It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. Excuse me? http://cvshome.org/docs/manual/cvs_21.html#SEC181 -Larry Jones What this games needs are negotiated settlements. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS Import
Title: CVS Import Hello, I went thru the Documentation for creating Import as well as FAQ. This is the scenario 1) I have a sources src_1, src_2, src_3 These are basically versions 1 2 3 of same code. Some files may have changed between the 3 versions. I am trying to import them into CVS as all the development is complete and CVS was not used during the Development of this Project. I use cvs import -m Message dir_to_import_on_cvs_repo vendor_tag release_tag_1 The first import was good. There was no problem at all. 2) Now I do a import for the second source with cvs import -m Message dir_to_import_on_cvs vendor_tag release_tag_2 This import also shows no errors. I do a cvs checkout in to another directory and in the status \ log do not see the versions as they should be seen or at least I think how they should be. i.e.: version with release_tag_1 i.e.: version with release_tag_2 I would expect a working revision of 1.1.1.2 I do not then try the 3rd Import. Conf: It is Red Hat Linux 7.0 cvs 1.11.1p1 (CVS Server) client 1.11 on Solaris 5.7 Result of cvs status -v dr.java File: dr.java Status: Up-to-date Working revision: 1.1.1.1 Repository revision: 1.1.1.1 path_in_repo/dr.java,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: start_553 (revision: 1.1.1.1) gui (branch: 1.1.1) 2) or is there any better way of doing it. or some point I am missing. If I have missed out any data please do let me know I will submit it and if there is a documentation note that I am missing please let me know the address. Thank you very much in advance and if this issue was addressed I apologize in advance but do let me know the location of the Document nevertheless. Regards, Rajesh
Re: cvs log -r
Thanks a lot for the tip! I'll give this a shot and see if I can
make this work for me.
-zach
On Sat, Jul 07, 2001 at 12:21:19AM -0700, Chuck Rossi wrote:
On Fri, Jul 06, 2001 at 01:55:15PM -0700, Chuck Rossi wrote:
On Fri, Jul 06, 2001 at 03:03:01PM -0400, Larry Jones wrote:
Zachary M. Smith writes:
i am getting errors similar to this:
cvs log -N -rr011860:r011870
cvs server: warning: no revision `r011860' in
`/source/module/Attic/something.c,v'
Then that's what I said: if either of the tags doesn't exist, you get
the entire revision history.
..for that file. Many of the past threads mention this problem
clearly.
I have read the various threads about cvs log and cvs rlog not doing
what one expects when run with -rtag1:tag2. I think I'm seeing a
problem - or not understanding something:
I have two tags on the same branch (rel2). 'cvs rdiff' does the
correct thing when I ask it what changed between two tags on that branch:
% cvs -q rdiff -kk -s -rbuild-1261 -rbuild-1263 tree3
File tree3/apps/uninst/myuninst/myuninst.cpp changed from revision 1.7 to 1.7.4.1
File tree3/lib/mycontrol/mycontrolmy.c changed from revision 1.91.8.3 to 1.91.8.4
File tree3/ui/data/htmlhelp/desktop/mytt.hhp changed from revision 1.7 to 1.7.10.1
However, 'cvs [r]log' gives back the last log entry for _every_ file in the tree:
% cvs -q rlog -N -rbuild-1261:build-1263 tree3
This is with cvs 1.11.1p1 on the client and server.
This is what I did to work around it:
% cvs -q log -N -rrel2 `cvs -q rdiff -s -rbuild-1261 -rbuild-1263 tree3 | sed
-e's/^File tree3\///' -e's/ changed.*$//' -e'/^$/d' -e'/ /d'`
Actually, after talking to David Taylor, this would be better:
% cvs -q log -N -rbuild-1261 -rbuild-1263 `cvs -q rdiff -s -rbuild-1261
-rbuild-1263 tree3 | awk '{print $2}'`
chuckr
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS loginfo use with pserver
Edouard Cugni writes: I have thought that I can use the log.pl script to achieve a nice log file for each project, but I just discovered that all entries are done with the account name (user) of the server, and not the name of the guy who commited the changes ! You need to pass the -u command line option to log.pl to set the correct user name. Your loginfo file should look something like: ALL $CVSROOT/CVSROOT/log.pl -u $USER -f $CVSROOT/CVSROOT/commitlog %s -Larry Jones (Note that $CVSROOT and $USER are CVS internal variables, *not* environment variables.) Start tying the sheets together. We'll go out the window. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Import
Rajesh Patwardhan writes: I use cvs import -m Message dir_to_import_on_cvs_repo vendor_tag release_tag_1 The first import was good. There was no problem at all. 2) Now I do a import for the second source with cvs import -m Message dir_to_import_on_cvs vendor_tag release_tag_2 This import also shows no errors. It is a good idea at this point to do a merge checkout to detect any files that were deleted between the two releases: cvs co -jrelease_tag_1 -jrelease_tag_2 dir_to_import_on_cvs cd dir_to_import_on_cvs cvs commit -m'merge' I do a cvs checkout in to another directory and in the status \ log do not see the versions as they should be seen or at least I think how they should be. i.e.: version with release_tag_1 i.e.: version with release_tag_2 I would expect a working revision of 1.1.1.2 If the file is exactly the same in both releases, CVS doesn't bother to create a new revision, it just applies the new release tag to the existing revision. -Larry Jones ...That would be pretty cool, if they weren't out to kill me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Protocol error: uncounted data discarded
On Sat, Jul 07, 2001 at 09:09:27AM -0700, John Minnihan wrote: Hi Chris, I have seen this too, but not consistently. For me, the error occurs only near the end of a very large checkout using a 'universe' defining module name. The error does not exhibit during smaller module checkouts, and as I said - it does not consistently show up even during the large checkouts. I'm curious what you see as the difference between 'in a buld script' and 'by hand'. It's strange. If I run the cvs operation from my Perl build script, I get Protocol error torwards the end of the checkout. If I execute the same command, in the same directory from a shell prompt, the checkout works fine. I'm surprised more people aren't running into this problem. I'm not doing anything special and my repository is not that big. Chuckr [EMAIL PROTECTED] wrote: Has there been any update on this? I made the mistake of upgrading one of my servers and one of my build machines to 1.11.1p1 and now I get this whenever I try a build using a build script: /usr/bin/cvs -q co -r build-1266 tree3 Protocol error: uncounted data discarded The client is a Linux RH 6.0 2.2.17 box. The server is a Linux RH 6.2 2.2.14-5.0smp box. Doing the same thing by hand seems to always work. Thanks... chuckr On Fri, May 04, 2001 at 04:23:14PM -0400, Chris Sharpe wrote: I just upgraded by Solaris (sparc) pserver to cvs 1.11.1p1 and from a WinNT command line cvs 1.11 client, I sometimes get the following error: cvs -d $my_cvsroot -f -r -q -z3 checkout -r $my_tag $my_module Protocol error: uncounted data discarded The module is about 3000 files in size and I've seen this a couple of times when running the checkout command as part of a script. Other modules checked out immediately after the failure work fine and if I try to checkout this module again, it works fine. I saw that there was a FIXME comment recently added by Derek in server.c that might be related. Anyone have any insight? Is this error related to 1.11.1p1 or is the timing just a coincidence (I never saw this error with 1.11 pserver). +---+ | Chris Sharpe KF4WVO Author of The Unofficial PEZ FAQ | | [EMAIL PROTECTED] PEZ - A treat to eat in a toy that's neat| +---+ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- _ John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS restricte ssh access
Hi guys, perhaps this is a bit off-topic... Anyway, I need to share a CVS repository located in my Personal directory on a Unix machine with a couple of developers. We have no support from the system people so I cannot create new groups/accounts etc. Is there any way to grant these people access via SSH *only* to use cvs?? I tried running ssh connection in a restricted shell (via a command option in the authorized-keys file) but I get this: bash: Root: command not found bash: Valid-responses: command not found bash: valid-requests: command not found Any ideas on how to pull this out?? Thank you, -- Giuseppe ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS comments
On Mon, Jul 09, 2001 at 11:13:57AM +0100, Steve Platt wrote: I'm trying to get out of CVS the comments put in(or not!!) by my developers, when they commit a module into CVS. I have looked at the history command and the log command, but can't see how this is achieved. cvs log is indeed what you're looking for. If it's not showing any commit messages, it's because there aren't any :-( -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. - RFC 1925 (quoting an unnamed source) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
Has anyone considered coding a little helper, say, an animated paper clip, that'll help people through the index of the manual? All right! Who threw the tomato? Regards, Mike Klinke - Original Message - From: Larry Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 09, 2001 10:40 AM Subject: Re: cvs [commit aborted]: cannot commit files as 'root' | Greg A. Woods writes: | | It isn't even in the manual, as far as I can see. That's maybe the | worst failing of the manual -- there's no (even partial) list of the | error messages in one place with links to nodes containing their | explanations. | | Excuse me? | | http://cvshome.org/docs/manual/cvs_21.html#SEC181 | | -Larry Jones | | What this games needs are negotiated settlements. -- Calvin | | ___ | Info-cvs mailing list | [EMAIL PROTECTED] | http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Protocol error: uncounted data discarded
[EMAIL PROTECTED] wrote: On Sat, Jul 07, 2001 at 09:09:27AM -0700, John Minnihan wrote: Hi Chris, I have seen this too, but not consistently. For me, the error occurs only near the end of a very large checkout using a 'universe' defining module name. The error does not exhibit during smaller module checkouts, and as I said - it does not consistently show up even during the large checkouts. I'm curious what you see as the difference between 'in a buld script' and 'by hand'. It's strange. If I run the cvs operation from my Perl build script, I get Protocol error torwards the end of the checkout. If I execute the same command, in the same directory from a shell prompt, the checkout works fine. I'm surprised more people aren't running into this problem. I'm not doing anything special and my repository is not that big. Perhaps this is related to the size (I'm out of my element here) of the stack/space/threads (or whatever) available to the CVS exe that was launched inside the script? That may explain why you don't see the error from a direct command-line invocation. I don't know how to check for this though. FTR - my error shows up when invoked from a perl script as well, though not every time. hmmm... Chuckr -- John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs [commit aborted]: cannot commit files as 'root'
[ On Monday, July 9, 2001 at 11:40:28 (-0400), Larry Jones wrote: ] Subject: Re: cvs [commit aborted]: cannot commit files as 'root' Greg A. Woods writes: It isn't even in the manual, as far as I can see. That's maybe the worst failing of the manual -- there's no (even partial) list of the error messages in one place with links to nodes containing their explanations. Excuse me? http://cvshome.org/docs/manual/cvs_21.html#SEC181 Ah, so there is! Sorry! Maybe what the manual needs more than anything else is a top-level complete table of contents listing every node in the menu (much like the The Detailed Node Listing in the Emacs manual and so many other wonderful texinfo-based manuals). The texinfo index is wonderful, and all, but it's just an index. I've come to expect the detailed listing and given there's no obvious way to restrict a search in 'info' to the current node, or to headings only, it's hard to find a node that you don't know exists. I don't know if there are any existing tools to help build the menu and detailed node listing, or not... -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] [EMAIL PROTECTED] Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Protocol error: uncounted data discarded
FWIW, my workaround was to determine if the checkout really got anything (by testing for existence of the directory or file) and sleeping for ten seconds and trying again. The retry has never failed. Odd. Checking the exit status of cvs wasn't reliable. It returned '0'. I would have expected this error to cause a non-zero exit status. --Chris On Mon, 9 Jul 2001, Chuck Rossi wrote: On Sat, Jul 07, 2001 at 09:09:27AM -0700, John Minnihan wrote: Hi Chris, I have seen this too, but not consistently. For me, the error occurs only near the end of a very large checkout using a 'universe' defining module name. The error does not exhibit during smaller module checkouts, and as I said - it does not consistently show up even during the large checkouts. I'm curious what you see as the difference between 'in a buld script' and 'by hand'. It's strange. If I run the cvs operation from my Perl build script, I get Protocol error torwards the end of the checkout. If I execute the same command, in the same directory from a shell prompt, the checkout works fine. I'm surprised more people aren't running into this problem. I'm not doing anything special and my repository is not that big. Chuckr [EMAIL PROTECTED] wrote: Has there been any update on this? I made the mistake of upgrading one of my servers and one of my build machines to 1.11.1p1 and now I get this whenever I try a build using a build script: /usr/bin/cvs -q co -r build-1266 tree3 Protocol error: uncounted data discarded The client is a Linux RH 6.0 2.2.17 box. The server is a Linux RH 6.2 2.2.14-5.0smp box. Doing the same thing by hand seems to always work. Thanks... chuckr On Fri, May 04, 2001 at 04:23:14PM -0400, Chris Sharpe wrote: I just upgraded by Solaris (sparc) pserver to cvs 1.11.1p1 and from a WinNT command line cvs 1.11 client, I sometimes get the following error: cvs -d $my_cvsroot -f -r -q -z3 checkout -r $my_tag $my_module Protocol error: uncounted data discarded The module is about 3000 files in size and I've seen this a couple of times when running the checkout command as part of a script. Other modules checked out immediately after the failure work fine and if I try to checkout this module again, it works fine. I saw that there was a FIXME comment recently added by Derek in server.c that might be related. Anyone have any insight? Is this error related to 1.11.1p1 or is the timing just a coincidence (I never saw this error with 1.11 pserver). +---+ | Chris Sharpe KF4WVO Author of The Unofficial PEZ FAQ | | [EMAIL PROTECTED] PEZ - A treat to eat in a toy that's neat| +---+ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- _ John Minnihan mailto:[EMAIL PROTECTED] http://www.freepository.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs +---+ | Chris Sharpe KF4WVO Author of The Unofficial PEZ FAQ | | [EMAIL PROTECTED] PEZ - A treat to eat in a toy that's neat| +---+ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
