Re: can't ./configure
[chris@chris cvs]$ ./configure bash: ./configure: No such file or directory Look at the first line of the file, the one that usually says something like #!/bin/sh You get the "No such file or directory" message if the file on the first line is missing or over 30 characters. HTH, Mark. -- Mark Harrison AsiaInfo Holding, Inc. [EMAIL PROTECTED]Beijing/Santa Clara
Re: Files created on Branch
1.10.8 is running on both server and client in pserver mode On Fri, 16 Jun 2000, Eric Siegerman wrote: Which version of CVS? I just tried this using 1.10.8 and it worked fine. On Thu, Jun 15, 2000 at 01:58:39PM -0400, Kevin C. Castner wrote: I have files that were created on a branch (Create the file) cvs co -r branch_name doc cd doc touch index.htm cvs add index.htm cvs commit index.htm Now I try to merge the file back to the main trunk. cd .. rm -rf doc cvs co doc cd doc cvs update -j branch_name cvs commit index.htm CVS then gives me the following error: cvs server: cannot add file `index.htm' when RCS file `/export/home/cvs/netops/doc/index.htm,v' already exists cvs [server aborted]: correct above errors first! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
Re: Files created on Branch
We are using 1.10.8 in local mode and via rsh. Shane Eric Siegerman wrote: Which version of CVS? I just tried this using 1.10.8 and it worked fine.
Re: .trunk patch refinement
Well, I see one problem with my patch already: --- Stephen Cameron [EMAIL PROTECTED] wrote: This part, from cvs.texinfo: + + CAUTION: the special tag `HEAD' is interpreted by + the `cvs diff' command in a different way than it + is interpreted by any other cvs command. `cvs diff' + takes `-r HEAD' to mean the following, as nearly as + I can tell: + + For `cvs diff', `HEAD' means the most recent revision + on the `current branch' (taking into account whatever + sticky tags are active in your working directory) unless + the particular file being diffed is not present on the + branch, in which case the head revision of the trunk is + taken. It is evident that there are at least some cases + for which this definition fails, that is, the wrong + revision may be found by `cvs diff' when used in combination + with `-r HEAD'. You may wish to use `.trunk' rather than + `HEAD'. The `.trunk' tag acts as a branch tag name for the + trunk. + is not correct nor consistent with this part: /* ! * Special tags. ! * -rHEAD refers to the tip revision on the trunk, _except_ for ! * "cvs diff". "cvs diff" interprets -rHEAD to mean the tip ! * revision of the current branch, however, that behavior is ! * broken, because if the file has not been branched, that is, ! * the revision on the branch is the same one that's on the trunk ! * then the tip revision of the trunk is reported. Also, it's ! * not clear (to me) what happens in the instance of a sticky ! * non-branch tag what -rHEAD is supposed to mean. So, -rHEAD ! * is probably a lost cause, unless you redefine what it means. ! * from cvs.h, which I think is more correct... So I need to fix that. -- steve __ Do You Yahoo!? Send instant messages with Yahoo! Messenger. http://im.yahoo.com/
ANNOUNCE: CVS Manual Translation Project Release 0.3.4
Begin3 Title: CVSMTP Version:0.3.4 Entered-date: 19Jun00 Description:CVS Manual Translation Project (CVSMTP) Project to translate the CVS documentation into german and other languages. Coordination should be done by e-mailing to the author. A mailing list does exist for further details take a look on the web-site. Keywords: documentation CVS german italian frensh portuguese Author: [EMAIL PROTECTED] (Karl Heinz Marbaise) [EMAIL PROTECTED] (Carsten Frewert) [EMAIL PROTECTED] (Malimpensa Stefano) [EMAIL PROTECTED] (Mark Soiseth) [EMAIL PROTECTED] (Thomas Tschoepke Soares) Maintained-by: [EMAIL PROTECTED] (Karl Heinz Marbaise) Primary-site: http://www.fido.de/~kama/cvsmtp/cvsmtp.html 720kB ftp://ftp.fido.de/pub/cvs/cvsmtp-0.3.4.tar.gz 170kB ftp://ftp.fido.de/pub/cvs/cvsmtp-src-0.3.4.tar.gz Alternate-site: Original-site: Platforms: Copying-policy: GPL Version 2.0 or later (see CVS manual) End -- Jabba dabba dooohhh e-mail: [EMAIL PROTECTED] 'til next mail.Internet: http://www.fido.de/~kama Karl Heinz 7:-) Fidonet: 2:2452/110.18 Voice: +49 241 962380
Subscribe
Please re subscribe me to the list. Gordon Stone Technical Author, Senior A/P World Online UK www.worldonline.co.uk Tel. +44 (0)870 748 4436 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 12 April 2000 13:56 To: [EMAIL PROTECTED] Subject: Re: Unsubscribe 32746 [EMAIL PROTECTED] [EMAIL PROTECTED] You have been removed from the list. If this wasn't your intention or you are having problems getting yourself unsubscribed, reply to this mail now (quoting it entirely (for diagnostic purposes), and of course adding any comments you see fit). Transcript of unsubscription request follows: -- From [EMAIL PROTECTED] Wed Apr 12 08:55:52 2000 Received: from telinco.net (internal.mail.telinco.net [212.1.128.4]) by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id IAA27614 for [EMAIL PROTECTED]; Wed, 12 Apr 2000 08:55:50 -0400 Received: from pilchards.telinco.net ([212.1.128.253] helo=DTUKNGORDONST) by telinco.net with smtp (Exim 3.02 #1) id 12fMgI-000D0G-00 for [EMAIL PROTECTED]; Wed, 12 Apr 2000 13:55:42 +0100 From: "Gordon Stone" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Unsubscribe Date: Wed, 12 Apr 2000 13:49:56 +0100 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal I hope this is the correct way to unsubscribe (only temporary over Easter period)
RE: .trunk patch refinement
Greg Woods wrote: [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ] Subject: ".trunk" patch refinement Ok, here's a refinement of my ".trunk' patch that gives the trunk a branch-tag name, just like other branches (from the user's perspective, the implementation is rather different.) OK, so exactly how is this different from "-r1"? Seems like it's the same thing to me, which means it's an awful waste of coding effort, not to mention the extra typing necessary to use it... ;-) [smc] ".trunk" has the possibility of handling the case where sombody has done "cvs commit -r2 foo", (though I haven't tested that case.) We've had this conversation before, actually, here's part of what we wrote:, (thanks deja.com) Greg Woods wrote: [...: ] It makes me wonder though if a magic pseudo-tag could even be implemented right in the case of bumped release numbers without jumping through a whole lot of hoops. I can't at the moment think of a way to inidicate to RCS that the top of the trunk should be always used without getting the "default branch" stuff involved and messing with that doesn't work well with CVS either since it's effectively reserved for internal use only. [smc] Yeah I think implementing what I want would be pretty hard... But, the changes might be at least localized to the RCS code, excepting any changes needed to handle a tag name that begins with a dot, (i.e. ".trunk" or something as mentioned in the docs. And then I went on to explain that I was "bullheaded enough" to want ".trunk" even though I didn't _need_ it. :-) -- steve
Re: can't ./configure
Chris Carbaugh writes: I've downloaded the source via that 'nifty' (yea right) java app cyclic has up now. That ``nifty'' Java app doesn't seem to work at all for me. If you continue to have problems, you might want to try going to the CVS download site (ftp://ftp.cvshome.org/pub/) and downloading the traditional gzipped tar file. -Larry Jones Even if lives DID hang in the balance, it would depend on whose they were. -- Calvin
RE: .trunk patch refinement
I wrote: Greg Woods wrote: [...] OK, so exactly how is this [my .trunk patch] different from "-r1"? Seems like it's the same thing to me, which means it's an awful waste of coding effort, not to mention the extra typing necessary to use it... ;-) [smc] ".trunk" has the possibility of handling the case where sombody has done "cvs commit -r2 foo", (though I haven't tested that case.) [smc] I just tried it. echo x x cvs add x cvs commit -m x x cvs tag one x echo 2 x cvs commit -r 2.1 -m x x cvs diff -r one -r1 x (no output, that is, the diffs between rev 1.1 and rev 1.1 ) cvs diff -r one -r.trunk x (you get the diffs between rev 1.1 and rev 2.1) I'll be adding such a case to sanity.sh in my patch later. (Does this justify the effort? who am I to say?) -- steve
[ANN] WinCvs 1.1b14 is out
http://devnet.3d.com/cvsweb/cvsweb.cgi/cvsgui/ChangeLog http://www.wincvs.org/download.html
RE: .trunk patch refinement
Mike Little [EMAIL PROTECTED] on 06/19/2000 09:12:42 AM To: "'[EMAIL PROTECTED]'" [EMAIL PROTECTED], "'[EMAIL PROTECTED]'" [EMAIL PROTECTED] cc:(bcc: Rex Jolliff/YM/RWDOE) Subject: RE: ".trunk" patch refinement -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [...] OK, so exactly how is this different from "-r1"? Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? I would just like to point out that trying to use CVS revision numbers as module or system version numbers is a bad, bad thing to do. This cannot be reiterated enough, and I realize that you did not suggest doing it Mike, but some people might get the mistaken impression that this use of revision numbers is not the mistake that it is. Rex.
RE: .trunk patch refinement
Greg Woods wrote: [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ] Subject: RE: ".trunk" patch refinement Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? I don't know for sure -- I never tried it. However people should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! (Yes, the manual gives instructions on how to do this -- it should not.) [smc] Other than perhaps to say, "don't do that." However, just because you shouldn't doesn't mean nobody will, if only out of ignorance, or by a typing accident, and pretty much anyone with commit access may do this, and once it's done, then what? Manually edit the RCS files to fix it? Abandon the repository in frustration and refuse to work with such idiots? This latter is more or less what you propose CVS should (continue to) do ;-) at least in the area of having a way to refer to the trunk other than a fresh checkout. There are at least a couple ways this can happen, one is "cvs commit -r" and another is copying in RCS files from someplace else. (The latter is the world I come from, so I've got lots of RCS files with weird revision numbers.) Sure, you may certainly say, "sorry, too bad, go away", but that's not what _I'm_ going to say. I will however concede that this ".trunk" feature is for me only a "nice-to-have" and not a "need-to-have", I've lived without it for 3 years now, and others have dealt with its absence for considerably longer than that. And as it happens our current development process involves committing to the trunk only rarely, when a branch is merged to the trunk. It's just something that's always bugged me that HEAD was so weirdly implemented and this "-r1" isn't obvious to anyone and only works by a quirk of RCS and then only under a limited set of circumstances, and when it doesn't work, it doesn't TELL you that it's not working so you easily might fail to notice that you'd generated the wrong diffs or whatever. (or the other probably more correct interpretation, -r1 works perfectly, if that's not what you wanted, well, sorry..) I would be interested in knowing about any other "corner cases" I might run into with my mal-formed repository that you might be aware of. -- steve
RE: .trunk patch refinement
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [...] OK, so exactly how is this different from "-r1"? Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? I would just like to point out that trying to use CVS revision numbers as module or system version numbers is a bad, bad thing to do. This cannot be reiterated enough, and I realize that you did not suggest doing it Mike, but some people might get the mistaken impression that this use of revision numbers is not the mistake that it is. What I don't understand is: If something is bad, why is it allowed. If using this feature is dangerous, then it should be removed from CVS. -- Stephen Rasku E-mail: [EMAIL PROTECTED] Senior Software EngineerPhone: (604) 872-6676 TGI TechnologiesWeb:http://www.tgivan.com/
Re: [ANN] WinCvs 1.1b14 is out
On Mon, 19 Jun 2000, Alexandre Parenteau wrote: http://devnet.3d.com/cvsweb/cvsweb.cgi/cvsgui/ChangeLog http://www.wincvs.org/download.html Whilst not actually on the webpage yet, the file is there at http://www.wincvs.org/WinCvs11b14.zip Mark -- Inspired by the taste of horror, proud to be insane forever Let out the killer in me! (c) Dismal Euphony Now Playing: no audio cd present
Re: .trunk patch refinement
[ On Monday, June 19, 2000 at 17:13:10 (-0500), David Thornley wrote: ] Subject: Re: ".trunk" patch refinement Since it's a very natural thing to do, lots of people have done it. It's easy (and correct) to say they should not have done that, but the important fact is that it has been done. However the important thing now is to continue to deprecate that practice. That includes removing the instructions for doing it from the manual (and replacing them with dire warnings against doing it), and most definitely not adding new code that's expressly designed to handle only one of the corner cases that this sillyness introduces. (If someone found some way to clean up *all* of the corner cases, and if they could justify the effort this would take even in the face of the design goal of using symbolic tags to identify such things, then that might be a somewhat different matter) Mike Little referred to "some previous cvs admin", and this is precisely what happened in my case. Some previous CVS admin put some of the rev numbers to 2.x, and there's no way I can put them back to 1.x. This has doubtless happened to many admins; either they inherited such a repository, or they created the problem themselves while not knowing better. It may be possible to renumber the trunk back to "normal", especially if there aren't too many branches in your repository Either way, any technique that assumes that all main trunk development is on rev numbers 1.* is useless to me, and probably to quite a few people. You can also leap-frog into a new repository starting fresh with "1.1" at some major milestone in your project. The actual amounts of use of history information is usually far lower than people surmise without measurements and indeed is extremely low if you only examine events where users back past a major milestone. You don't have to 100% cut them off from the old history either -- just keep it in a read-only repository for easy local access and then occasionally audit to see how often it's accessed before you retire it for good. -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
Re: .trunk patch refinement
David Thornley [EMAIL PROTECTED] writes: Either way, any technique that assumes that all main trunk development is on rev numbers 1.* is useless to me, and probably to quite a few people. And it's quite possible to get into that state without any misuse of CVS at any point. It's worth remembering that a lot of us are using CVS repositories formed from imported RCS files, and using different rev numbers with RCS is extremely common. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/
Re: .trunk patch refinement
I'm well aware that bumping trunk revisions to 2.x or greater is pretty useless, and that tags are the right way to go, especially since after you do it, newly-added files will still get 1.x revisions. However... On Mon, Jun 19, 2000 at 05:01:45PM -0400, Greg A. Woods wrote: However people should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! ... I wasn't aware that it's actively dangerous, as Greg seems to be saying. If so, is there any reason to keep it? Why not just make commit's -r option go away? [ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ] Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? "say -r1 when you mean latest-on-trunk" is a kludge, to work around the lack of ".trunk". That it fails on trunk revision 2.x isn't a corner case in CVS; it's a limitation of the kludge. The man's offering to obviate this kludge with a correct solution; what's all the grumbling about? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / [Microsoft's] www.hotmail.com is running Apache/1.3.6 (Unix) ... on FreeBSD - Netcraft's "What's that site running?" service, 12-Jun-2000
RE: .trunk patch refinement
[ On Monday, June 19, 2000 at 17:12:42 (+0100), Mike Little wrote: ] Subject: RE: ".trunk" patch refinement Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? I don't know for sure -- I never tried it. However people should *not* ever be doing such silly things -- there are more corner cases than just this one whre they can get into trouble! (Yes, the manual gives instructions on how to do this -- it should not.) -- Greg A. Woods +1 416 218-0098 VE3TCP [EMAIL PROTECTED] robohack!woods Planix, Inc. [EMAIL PROTECTED]; Secrets of the Weird [EMAIL PROTECTED]
RE: .trunk patch refinement
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, June 19, 2000 3:48 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: ".trunk" patch refinement [ On Saturday, June 17, 2000 at 21:41:49 (-0700), Stephen Cameron wrote: ] Subject: ".trunk" patch refinement Ok, here's a refinement of my ".trunk' patch that gives the trunk a branch-tag name, just like other branches (from the user's perspective, the implementation is rather different.) OK, so exactly how is this different from "-r1"? Seems like it's the same thing to me, which means it's an awful waste of coding effort, not to mention the extra typing necessary to use it... ;-) Would '-r1' work if some previous cvs admin had updated vast numbers of the trunk revisions to 3.x (presumably when version 3.0 of the product was released)? Mike -- Mike Little Share what you know. Learn what you don't. ServicePOWER Business Solutions Ltd home: [EMAIL PROTECTED]
