Re: intermittent cvs lock messages
> * Todd Denniston <[EMAIL PROTECTED]> [2005-05-26 09:43:34 -0500]:
>
> Sam Steingold wrote:
>>
>> I use
>> "Concurrent Versions System (CVS) 1.11.17 (client/server)"
>> via SSH on cygwin and linux.
>>
>> During CVS commit, I often get this messages:
>>
>> Message: [22:06:14] waiting for sds's lock in /cvsroot/clisp/clisp/tests
>>
>> [note, "sds" is myself]
>>
>> then, after a few minutes, commit succeeds.
>>
>
> two possibilities I can think of:
> 1) you are doing some other cvs operation at the same time. (which
> version(s) of CVS or/and CVS GUI/SSH agent/SSH clients are you using? or
> perhaps you use a script to do your commit, and it starts the secondary work
> too soon?)
as specified above:
CVS: "Concurrent Versions System (CVS) 1.11.17 (client/server)"
SSH: OpenSSH_4.0p1, OpenSSL 0.9.7g 11 Apr 2005
no scripts.
I use emacs cvs mode.
> 2) the project admins have put some kind of automatic tool in the
> committing script that does a cvs operation in your name. (you may
> have to ask the Project admins.)
I use loginfo to e-mail the commit information to a mailing list:
ALL /cvsroot/sitedocs/CVSROOT/cvstools/syncmail -u -f users.sourceforge.net
%{sVv} [EMAIL PROTECTED]
syncmail source code:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/cvs-syncmail/syncmail/syncmail
thanks for your reply.
--
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.dhimmi.com/> <http://www.mideasttruth.com/>
<http://ffii.org/> <http://pmw.org.il/> <http://www.camera.org>
The only time you have too much fuel is when you're on fire.
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
intermittent cvs lock messages
Hi, I use "Concurrent Versions System (CVS) 1.11.17 (client/server)" via SSH on cygwin and linux. During CVS commit, I often get this messages: Message: [22:06:14] waiting for sds's lock in /cvsroot/clisp/clisp/tests [note, "sds" is myself] then, after a few minutes, commit succeeds. I reported this to the repository maintainers and they said that there are no lock files there: <https://sourceforge.net/tracker/?func=detail&atid=21&aid=1203166&group_id=1> it appears that the locks are created by my client during commit: when I commit "foo", it locks "foo" and then tries to commit it and runs into its own lock (which it then reports back to me in the above message), and, after waiting for the lock to expire (in a few minutes), it proceeds with the commit. is this really the case? Thanks! -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.mideasttruth.com/> <http://www.iris.org.il> <http://www.memri.org/> <http://www.jihadwatch.org/> <http://www.camera.org> <http://www.dhimmi.com/> Only adults have difficulty with child-proof caps. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
changing revision number
I have a file foo at revision 1.1234. It was extensively modified and committed as 1.1235. I wish it were committed as 2.0 instead. What are my options? All I can think of at the moment is: 1. cvs admin -o 1.1235 foo 2. edit CVS/Entries 3. cvs ci -r 2.0 foo is there a better way? in particular, DIUC that "cvs ci -r 2.0 foo" will _add_ a revision 2.0 on top of 1.1235 (not replace 1.1235 with 2.0)? (I know about tags, and I do not wish to use them here. All I want is to change the revision number, that is all. I am not interested in branching &c &c) Thanks. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> WHO ATE MY BREAKFAST PANTS? ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
cvs admin -o does not modify CVS/Entries
if the latest version is 1.7 and I do $ cvs admin -o 1.7 foo then foo is still marked as 1.7 in CVS/Entries and thus I have to edit it by hand to be able to work on the file. -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.honestreporting.com> We're too busy mopping the floor to turn off the faucet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Fri, 12 Oct 2001 13:04:14 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On , October 12, 2001 at 10:59:41 (-0400), Sam Steingold wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > I wonder why "Greg A. Woods" could no say that as a reply to the _first_ > > message suggesting this. > > Because you could have figured this out with only the tiniest amount > of research on your own, including just reading the fine CVS manual > itself. the explanations are recent additions - they weren't there when I read the manual (a year ago?). Also, the manual does _not_ explain why cvs cannot do what is described in <http://www.cvshome.org/docs/manual/cvs_7.html#SEC72> with "cvs mv" and <http://www.cvshome.org/docs/manual/cvs_7.html#SEC73> with "cvs cp". especially the last one which has only one disadvantage -- * You cannot easily see the history of the file across the rename. whose meaning I don't understand. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> I want Tamagochi! -- What for? Your pet hamster is still alive! ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <6npx7.65227$[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 22:50:42 GMT > * Honorable [EMAIL PROTECTED] (Kaz Kylheku) writes: > > >why can't "cvs mv" just rename the *,v file? > > Because then if you check out (or export) an old tagged build of the > software, it will have the rename. And that will very likely break the > old build. > > A fundamental principle of version control is that when you label some > release of the software, it is fixed for posterity. Anyone can go back > and retrieve that release exactly. This capability essential if you > ever need to go back to that version and shoot off a bugfix branch, > for instance. > > In CVS, you can no longer do this if you start moving around the *,v > files. > > If you can't go back to tagged builds, then your version control > system is reduced to a mere piece of collaboration ``groupware'' at > best, and a file backup system at worst. ;) Oh my!!! Finally!!! Yess!!! Thanks!!! Now I see the light. I wonder why "Greg A. Woods" could no say that as a reply to the _first_ message suggesting this. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> We're too busy mopping the floor to turn off the faucet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 17:51:02 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On , October 11, 2001 at 15:48:02 (-0400), Sam Steingold wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > But calling "cvs add/rm" "the right way" instead of adding "cvs mv" is > > not correct - exactly because it leads us to the situation when CVS is > > expected to deny the truth. > > You need to understand the much deeper issues of trying to include > rename information in a change control tool, You really cannot add > such a feature to a file-based change tracking tool -- doing so takes > you far away from what CVS is. why? > > why? why can't "cvs mv" rename the *,v file? > > Nope -- no file-based change control tool can. You have to add a > whole mess of meta-data on top, and the more you think about all the > corner cases and side effects, the deeper the pile gets. Soon you end > up building a system that's completely the opposite of a file-based > change control tool -- i.e. one that constructs files out of sets of > changes that are probably stored in a more sophisticated database than > any unix-like filesystem can ever be on its own. why? why can't "cvs mv" just rename the *,v file? let me repeat: why can't "cvs mv" just rename the *,v file? > > > The effect on the revision tracking of such a grand renaming is really > > > no different than changing all the white space or indentation inside > > > of every file. > > > > I do not buy this. > > renaming a file does not change it's contents. > > but the EFFECT (on the change management process) is the same!!! why? > > Emacs has `vc-rename-file' and it supports both RCS and SCCS. > > Yes, this might not be native operations, but _this can be done_. > > I think you don't understand the larger issues here. What > vc-rename-file does breaks all kinds of things in the larger SCM > picture! It is a cheap hack that wise people would only use in very > limited circumstances. I am not saying I will be doing "cvs mv" twice a day. I have felt the need for it about twice in my life. The fact that CVS cannot do it is still haunting me. > > Thus, of all the tools accessible to me, only CVS refuses to rename > > files. > > CVS refuses to rename files because the CVS designers were aware of > all the deeper issues and they didn't want to create a situation worse > than the current "alternative". what can be worse?! cut the socialist crap. remember the 2nd amendment, give me the damned gun and explain me that I should be careful not to shoot myself -- but let _me_ decide what I want to do. > > Would you like to use a file system which lacked rename(2) syscall > well as a matter of fact the rename(2) call is a recent addition so? > BUT, You're trying to compare totally unrelated things here -- it > might look so simple on the surface, but when you have to keep track > of such operations over time requires much more than a simple rename > command! okay - so don't keep track! just rename the darn *,v files! yes, rename then would be global - all branches will be affected. so issue a warning! those who can be hurt by this will not use this. > > yes of course! but the mistake has been done already, long ago, and I > > wish I could undo it now. > > be careful what you wish for -- you may only create a worse nightmare. bull. I did a manual rename of *,v files in the CVS repository one. I have never had any problems with that. Everything works as expected. No problems. > If I were you I would break from the past and start fresh. Don't be ridiculous. I have users to support. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> Live Lisp and prosper. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 17:08:07 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > I suggest you do a survey of similar tools and count the number that > can do exactly what you want. I suspect you'll find that number to be > quite low and almost certainly only include high-end commercial > packages. As I said in another message, in Emacs, M-x vc-rename-file RET will work when the back-end is RCS or SCCS, but not when it is CVS. I have no idea what SCCS is, but I thought that RCS was _more_ primitive than CVS. All the problems you are talking about here (merging &c) arise for one simple reason - you do not have "cvs mv" and you make people think that "cvs add/rm" has anything to do with renaming. There are two levels to renaming: * you can go the "filesystem" way, do mv(1) and forget the old name completely, * or you can go the "change management: way, and remember the old name(s), permitting undo &c. Not providing _either_ is brain damage. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> .sigs are like your face - rarely seen by you and uglier than you think ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 13:03:50 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On Thursday, October 11, 2001 at 05:44:16 (GMT), Kaz Kylheku wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > In article <[EMAIL PROTECTED]>, Greg A. Woods wrote: > > >> * 'cvs log BAR' does not list changes in file FOO > > > > > >Of course not You do not want it to! That would be illogical. > > > > That is false. Just because the tool doesn't do something doesn't mean we > > don't *want* it or that it is illogical. Some version control tools can > > handle renames. The actual object being version is stored anonymously, > > and a path name is just another versioned property of that object. > > Let me repeat: You DO NOT want or need to have "cvs log BAR" list > changes in the file "FOO". To want that is illogical. It is > unnecessary! Could you please elaborate? _Why_ is it illogical? _Why_ is it unnecessary? Let me try to repeat: FOO and BAR here are the same file (like compiler.lisp and compiler.lsp). If FOO is renamed to BAR when it is at 1.125, then the change from FOO 1.123 to BAR 1.3 is a matter of 4 modifications: 1. FOO 1.123 --> FOO 1.124 2. FOO 1.124 --> FOO 1.125 == BAR 1.1 3. BAR 1.1 --> BAR 1.2 4. BAR 1.2 --> BAR 1.3 Why can't I see the log for all of them in one command? Consider a versioning file system which has a native idea of file version. I can rename file FOO; to BAR;, keeping the older versions of FOO named FOO;1, FOO;2 &c. - this corresponds to the CVS method (rm/add). But I also can rename _all_ version of FOO to BAR. This _is_ a reasonable thing to do. Why can't I do it with CVS? Please note that the answers like "this is not how CVS manages change!" are not very convincing, because the natural retort is "then maybe CVS manages change incorrectly?" Please tell us _why_ the request for the CVS command mv, which would rename the *,v file and replace the CVS/Entries entry is unreasonable. (Oh yeah, CVSROOT/history should also be suitably modified and a record of the renaming to allow for undoing it should also be added. But is these are too hard to implement, forget it and stick with a simple "mv FOO,v BAR,v"). And while I am talking about undoing, why can't a revision be removed from the CVS? just like I can remove a revision in a versioning file system, I should be able to remove a revision from the CVS. Don't get me wrong. CVS is a great tool. Let's make it even better! -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> The paperless office will become a reality soon after the paperless toilet. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 13:47:09 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On , October 11, 2001 at 10:39:50 (-0400), Sam Steingold wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > why? this is the same file. > no, actually it is not. yes, actually it is. you want me to look at the world through the tool-imposed blinders. no way. these files are the same, period. the issue is that CVS does not recognize that. Actually, now that the damage (i.e., "the right way" - cvs add/rm) has been done, CVS really has no reason to recognize the truth and admit that the files are the same. But calling "cvs add/rm" "the right way" instead of adding "cvs mv" is not correct - exactly because it leads us to the situation when CVS is expected to deny the truth. > CVS tracks changes ... thanks for repeating this. actually, I knew all this, but it was nice to here that my knowledge was correct. > > to use a very specific example: CLISP (http://clisp.cons.org) used "lsp" > > extension for CL files but switched to "lisp" a couple of years ago. > Hmmm that's a very outrageous example of an idiotic change with > no productive end result. you do not have to be rude. you do not know all the circumstances. I was not the one who did it. In the similar situation I did the right thing - the renaming at the file-system level, not the CVS level. > > This was done "the right way" as per CVS manual. > > Now we have two totally unrelated (from the CVS point of view) files: > > compiler.lisp and compiler.lsp. > > Actually, from the human point of view, these two are the different > > names of the same file, and being able to see the change history of this > > file _is_ a reasonable and logical thing! > > CVS is simply not designed to manage such large-scale renames. They > are far beyond the design goals of a simple file handling tool like > CVS. why? why can't "cvs mv" rename the *,v file? > The effect on the revision tracking of such a grand renaming is really > no different than changing all the white space or indentation inside > of every file. I do not buy this. renaming a file does not change it's contents. > Such structural changes to a project are usually best done at a major > milestone (eg. just after a major release) and at least with CVS are > usually handled best by starting fresh with a new module. huh? you mean CVS is no designed to keep the changes over many years and releases?! > That way you are not tempted to do things that would be illogical in > the first place. The same is true with SCCS and RCS, and no doubt > with TCCS, PRCS, Aegis, Perforce, and other similar tools too. Okay. I have never used TCCS, PRCS, Aegis, Perforce and SCCS. Emacs has `vc-rename-file' and it supports both RCS and SCCS. Yes, this might not be native operations, but _this can be done_. MS SourceSafe also can rename a file. Thus, of all the tools accessible to me, only CVS refuses to rename files. Would you like to use a file system which lacked rename(2) syscall and instead required one to do the following: $ cp FOO BAR $ rm FOO Let me repeat again: file renaming is a reasonable operation and it must be supported in a reasonable way. Just like cp+rm is not a reasonable replacement for mv, cvs add/rm is not a reasonable replacement for cvs mv. > > > > * there is no way to compare BAR 1.123 with FOO 1.321 > > > >[yeah, they are separated by over a hundred revisions, so what? > > > > there are still situations when this makes sense.] > > > > > > Bull. It's trivial to do. > > > > please! how do I do that without going through this: > > $ cvs co -p -r 1.123 BAR > BAR.1.123 > > $ cvs co -p -r 1.321 FOO > FOO.1.321 > > $ diff BAR.1.123 FOO.1.321 > > Huh? You have your result! What are you asking? I am asking that I do not have to be forced to jump over my head to achieve a trivial result. > > Let me repeat: I have two files: (with _many_ revisions) > > and (with even _more_ revisions). > > I need to create a file compiler.lisp,v with _all_ these revisions, > > sequentially, first those from , then from > > . > > I think you are asking the wrong question. > > You have not stated the base requirement which seems to be driving > your desire to do this. I want to be able to see the change history for compiler.lisp &c. > If your goal is simply to forget that you ever had *.lsp files then > obviously it would have been easier to simply rename
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Thu, 11 Oct 2001 01:03:59 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On , October 10, 2001 at 17:31:23 (-0400), Sam Steingold wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > * 'cvs log BAR' does not list changes in file FOO > Of course not You do not want it to! That would be illogical. why? this is the same file. to use a very specific example: CLISP (http://clisp.cons.org) used "lsp" extension for CL files but switched to "lisp" a couple of years ago. This was done "the right way" as per CVS manual. Now we have two totally unrelated (from the CVS point of view) files: compiler.lisp and compiler.lsp. Actually, from the human point of view, these two are the different names of the same file, and being able to see the change history of this file _is_ a reasonable and logical thing! > > * there is no way to compare BAR 1.123 with FOO 1.321 > >[yeah, they are separated by over a hundred revisions, so what? > > there are still situations when this makes sense.] > > Bull. It's trivial to do. please! how do I do that without going through this: $ cvs co -p -r 1.123 BAR > BAR.1.123 $ cvs co -p -r 1.321 FOO > FOO.1.321 $ diff BAR.1.123 FOO.1.321 > > --> etc - CVS does not know that FOO is the old name for BAR. > > > > * also, this operation cannot be undone gracefully: when I do the above > >renaming backwards, CVS moves BAR,v into the attic and there is no > >way to get the revisions of BAR into the FOO,v file > >(or is there - how do I concat two *,v files?!) > > It's trivial to "undo" too -- the same way you "undo" any commit. okay. I _really_ do need this, and I will greatly appreciate an instruction on how to do this. Let me repeat: I have two files: (with _many_ revisions) and (with even _more_ revisions). I need to create a file compiler.lisp,v with _all_ these revisions, sequentially, first those from , then from . The only thing I can think of is: check out and patch it, one by one, with all the patches that went into , then go (using shell) into the CVS repository and rename to . The problem is that there are 64 such files, so this process will have to be automated somehow. BTW, is there any difference, from the CVS POV, between $ cvs ci -m mesg FOO BAR and $ cvs ci -m mesg FOO $ cvs ci -m mesg BAR ? the reason I am asking is that some files have been checked in together, so I will need to do some trickery to check the diffs into the old names together too. > > The problem is that I do not always have shell access - then I am stuck. > You don't need to have shell-level access to the repository. this is very nice to hear. could you please tell me what to do? I hope I made my needs quite clear already. -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> The program isn't debugged until the last user is dead. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: [kfogel@collab.net: Re: rename in cvs]
> * In message <[EMAIL PROTECTED]> > * On the subject of "Re: [[EMAIL PROTECTED]: Re: rename in cvs]" > * Sent on Wed, 10 Oct 2001 15:06:14 -0400 (EDT) > * Honorable [EMAIL PROTECTED] (Greg A. Woods) writes: > > [ On Wednesday, October 10, 2001 at 10:52:04 (-0700), Paul Sander wrote: ] > > Subject: Re: [[EMAIL PROTECTED]: Re: rename in cvs] > > > > Generally speaking, renaming stuff in CVS is royal pain. You always lose > > something. It's up to you to decide what you're willing to give up. > > You never loose anything if you do it right. > (and assuming some bugs are fixed in some ancillary sub-commands) if you rename FOO to BAR "the right way", i.e., $ mv FOO BAR $ cvs rm FOO $ cvs add BAR $ cvs ci BAR then you lose in many ways: * 'cvs log BAR' does not list changes in file FOO * there is no way to compare BAR 1.123 with FOO 1.321 [yeah, they are separated by over a hundred revisions, so what? there are still situations when this makes sense.] --> etc - CVS does not know that FOO is the old name for BAR. * also, this operation cannot be undone gracefully: when I do the above renaming backwards, CVS moves BAR,v into the attic and there is no way to get the revisions of BAR into the FOO,v file (or is there - how do I concat two *,v files?!) This is why I usually rename the *,v files, edit them manually to replace file names in $Id$ and also edit history. The problem is that I do not always have shell access - then I am stuck. Ideally I want to be able to say $ cvs rename -r 2.0 FOO BAR so that BAR 2.0 is the same as the current FOO. then BAR 1.123 will be the same as FOO 1.123. CVS would know that FOO and BAR are the same logical file. $ cvs co -r 1.123 BAR and $ cvs co -r 1.123 FOO would create a file named FOO while $ cvs co -r 2.0 BAR and $ cvs co -r 2.0 FOO would create a file named BAR -- Sam Steingold (http://www.podval.org/~sds) Support Israel's right to defend herself! <http://www.i-charity.com/go/israel> Read what the Arab leaders say to their people on <http://www.memri.org/> Only adults have difficulty with childproof caps. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
