Re: gpl version 2 for cvs
Hi Larry.
I was only talking about US copyright law. I don't know the answer
for a fact myself, it's not like I know where to look in the civil
code.
Everything you need to know can be found at the US Copyright
Office's web site: http://www.loc.gov/copyright/.
Under UK copyright law, the opposite is true: If copyright is
claimed for more than two consecutive years, then they MUST be
specified as a range to be legally valid.
Has the UK not signed the Berne Convention? The whole point of it
was to avoid such gratuitous differences. (The Berne Convention
doesn't require any notice at all, let alone a specific form of
notice.)
I've no idea whether the UK has signed the stated convention, but one
point was repeatedly emphasised in a copyright case in which I was
present back in November 2001: If there is no notice stating the year
for which copyright is claimed, then the whole idea of copyright is open
to fraud. The decision as far as that case is concerned was that for
copyright to hold, the item must include a statement that includes the
most recent year for which copyright is claimed.
My understanding is that the following bash script prints a copyright
notice that is both full and sufficient as far as both UK and US law
is concerned, and also puts the software under version 2 of the GPL
(assuming appropriate definitions of the environment variables TITLE
and AUTHOR for the software in question):
#!/bin/bash
echo ${TITLE}
echo Copyright (C) `date +%Y,` ${AUTHOR}
echo Released under the GNU General Public Licence, version 2.
Note that under UK law, it is NOT valid to refer to a licence that has
not yet been written, so the fabled or, at your option, any later
version is invalid here.
Best wishes from Riley.
___
Bug-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: Added directories not reflected on update
Hi Joanna, Larry. Synopsis: if user a does cvs add newdir and user b does cvs update, user b does not get newdir. Until user a does cvs commit there's nothing for user b to create as user a could still decide that directory isn't needed after all. You need to give update the -d option to create new directories. I have to admit that I would personally prefer for the meaning of -d to be inverted there, but it's probably far too late to do that now. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. I see a problem with the CVS code as distributed. That is, it has a single csh script which is both slow and makes the CVS code-base depend on an additional unix utility when it doesn't have to. Well, it's only a contributed utility, not a core part of the CVS code as distributed. All the Linux distributions I have access too include sccs2rcs as part of the CVS package because it is distributed as part of the CVS tar ball. Because of that, I consider it part of CVS. I run Red Hat 6.2 here, with CVS installed from RPM. I've just checked, and no such file exists either on my system or in the CVS RPM. Could you advise where it's gone please? I believe I addressed both of these problems with my re-write of the script in perl. No, you did not. Only a translation to POSIX Shell or C would have addressed both problems. If somebody wishes to send me a copy of the script in question, I'll translate it to bash for you if that's possible. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. Hi Riley -- Thanks for the reply. At least now I know that my mail is being seen by someone other than myself. NP. Let me address your points at they go... I'm not on the CVS development team as such, just being a very happy user of CVS... Oh, don't be fooled -- I'm a very happy user of CVS too. I just use SCCS in my day job because that's what we've always used, but that's changing these days -- mostly with the help of the sccs2rcs perl script that I included before. As stated in my original email, I never managed to get on with SCCS on the only occasion I was expected to use it, so can't really comment on it in any sort of meaningful way... ...but I would like to offer one possible reason for the lack of comments: Perhaps those on the list here are like me and don't use SCCS in the first place, so have no use for the script. True, that could be a reason, but you may be missing the fact that I'm not advocating the *addition* of a script, but a *replacement* of a script. If you think about it, you'll soon realise that the difference you refer to is irrelevant to anybody who doesn't use SCCS - if they don't use SCCS, then they will have no interest whatsoever in the existence of a script to convert from SCCS to CVS, much less in how well (or even whether) the script in question works. If you check your CVS distribution, you'll find in the contrib directory a sccs2rcs script *already* there. However, it is written in csh which is A) slow B) one more dependency for your .deb or .rpm to depend on. The perl script that I'm requesting consideration addresses both of these issues since the perl script runs about twice as fast as the csh version and, since there are already perl scripts in the CVS distribution, adds *no* additional dependencies. To get any comments on either your script or the original one, you'd need to find somebody else who uses both SCCS and CVS and needs to convert from SCCS to CVS. Other than that, to be honest, nobody's going to be interested for the simple reason that they've no reasonable means to test either script. Another possibility is the length of the To: and CC: list in your email - I know several people who have their system set up to auto-kill any emails with more than three names in those two combined simply as a way to cut down the amount of mail they have to handle, and your email would not have made it to any of them. I have sent this email already twice before -- once to bug-cvs and once to user-cvs with very reasonable To: and CC: lines so I don't think this is the reason. I'm on the bug-cvs list but not on the user-cvs list, and I've never seen your email before the one I replied to. I've been on the bug-cvs list since last September, so wouldn't have seen it if posted before then, but if posted since, it apparently didn't get through to that list, which could explain the lack of response... I've also written to Larry Jones (who seems to be the primary person committing to the CVS source tree) directly and I got *no* reply - not even a go away or not interested! That much I can't comment on as I don't know Larry's circumstances. However, if they're anything like me, he probably doesn't have the time to even read, much less reply to, emails about things he's not directly interested in. To put that in context, allow that (after my spam-filter has finished with them) I receive between 500 and 700 emails a day, mostly from the Linux-Kernel or the UK-Genealogy mailing lists, and if I even read every email I received, I'd have little time to do anything else. As it happens, I read every mail posted to the Linux-8086, Linux-Hams and Bug-CVS mailing lists, but I only reply to ones where I can make a positive contribution of some sort. With most of the mailing lists I receive, I decide whether to read a particular email based on (a) the sender is somebody important on that list (I read EVERY email from either Linus Torvalds or Alan Cox on the Linux-Kernel list), or (b) the subject line catches my attention. If neither of those apply, the email doesn't get read - it's as simple as that. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: sccs2rcs to perl
Hi Michael. My monthly resend of this script. I guess I'll include the script directly this time in the hopes that maybe people don't like attachments and that's the reason I still haven't gotten a response from anyone in the CVS development team. The script (sccs2rcs.in) is attached in-line after the original message. It would be nice to receive some comment from the CVS development team. This is the third time I've sent this out the the mailing lists with not a peep from anyone about it. Very disappointing. I'm not on the CVS development team as such, just being a very happy user of CVS, but I would like to offer one possible reason for the lack of comments: Perhaps those on the list here are like me and don't use SCCS in the first place, so have no use for the script. Another possibility is the length of the To: and CC: list in your email - I know several people who have their system set up to auto-kill any emails with more than three names in those two combined simply as a way to cut down the amount of mail they have to handle, and your email would not have made it to any of them. I will add that at University not so long ago, we were expected to use SCCS for our CS projects, but I coul;dn't get the hang of using SCCS there, so never made any real use of it. I don't know whether this was SCCS in general or the way they had it set up, as I've never even looked at using it elsewhere, but I do know that I was using CVS shortly after coming across it and installing it on my RedHat Linux system. Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Feature request
Hi there. One tweak I would like to see made to cvs is concerning the `cvs diff` command. On my Red Hat Linux based system, I note the following line in the output of the `man diff` command... -b Ignore changes in amount of white space. ...which describes a feature that is very useful when somebody has reindented the code in a particular file, so one can see the changes that have been made without having to decide for each and every line whether it's just a tweak in the whitespace layout. Is there any possibility of this being implemented in the `cvs diff` command or is this considered too esotoric a facility? Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
Re: New email address
Hi Brian. Brian Behlendorf tells me that Collab Net will be supporting the bandwidth and hardware for cvshome.org for an indefinite period. Are you sure of this? As of yesterday morning, I've been unable to get to cvshome.org either by web or cvs pserver, so as far as I can tell, it's already dead... The server is definitely up - we moved it to a new network location on Friday and had some resulting routing issues, causing some hefty downtime then, but it should be back up. If you get a clearer idea of in what way the system is down for you (DNS won't resolve or goes to an older IP address, IP address can't be reached, IP address is reachable but connectivity is poor, or IP address connectivity is good but nothing's listening on port 80) then let me know and I'll look at it. When I had a look for it on Sunday morning, I found the following mappings (from memory): cvs.cvshome.org 127.0.0.9 www.cvshome.org 127.0.0.15 Both were 127.0.0.* addresses, and neither was valid - the only valid 127.* addresses here are 127.0.0.1 and 127.0.0.255 !!! I've just tried again, and see the following mapping at the moment: cvs.cvshome.org 64.125.132.231 64.125.132.213 www.cvshome.org 64.125.132.231 I'm not sure whether there should be two IP's for the cvs server, but I see two in response to the `host cvs.cvshome.org` command here, although only one shows up to `host www.cvshome.org` at this time. Based on that, I've just done `cvs update -d -P` from the directory I downloaded the CVS tree to, and get... ===8=== CUT ===8=== $ cvs update -d -P cvs [update aborted]: connect to cvs.cvshome.org(64.125.132.231):2401 failed: connection refused $ ===8=== CUT ===8=== ...which is the same message, but with an IP address that is at least valid - the previous one was not. In case it helps, I've enclosed a traceroute to cvs.cvshome.org when it selected that IP... CollabNet will continue to support the CVS community and codebase by hosting cvshome.org for the indefinite future. The bandwidth load is pretty modest, we're OK on hardware allocations, so it's not a problem. Derek's indicated a willingness to continue administering it, which I definitely appreciate. That I'm certainly glad to hear. These economic times are very tough, and last week CollabNet had to let some very valuable people go, including Derek. He assisted us tremendously with some pretty deep CVS problems, much of the results of which ended up as contributions back (on CVS and other projects as well). If any of you are using CVS in demanding situations and looking to hire a guru, I would recommend him highly. If I was in a position to do so, I'm sure I would. Ufortunately, I'm also the possessor of far too much free time, for similar reasons :( Best wishes from Riley. traceroute to cvs.cvshome.org (64.125.132.231), 30 hops max, 38 byte packets 1 leopard.lns.birmingham.access.planet.net.uk (195.92.168.22) 113.715 ms * 1498.844 ms 2 * PBR-1.BRM.AS5388.NET (195.92.168.2) 111.201 ms * 3 BNR-2.BRM.AS5388.NET (195.92.169.3) 2239.281 ms 2322.246 ms 1158.991 ms 4 BNR-1.TCL.AS5388.NET (195.92.201.153) 118.801 ms 2461.639 ms * 5 BNR-2.TCL.AS5388.NET (195.92.200.195) 2739.316 ms 2634.588 ms * 6 pomegranate.AS5388.NET (195.92.201.13) 2100.165 ms 1577.329 ms * 7 linx.london.above.net (195.66.224.76) 2729.521 ms * * 8 lga1-lhr1-stm4.lga1.above.net (208.184.231.21) 196.944 ms 2450.044 ms * 9 * * iad1-lga1-oc192-2.iad1.above.net (208.184.233.61) 1339.991 ms 10 core1-core4-oc48.iad1.above.net (208.185.0.137) 2061.354 ms * 219.314 ms 11 sjc2-iad1-oc48.sjc2.above.net (216.200.127.26) 270.791 ms 1069.196 ms * 12 sfo1-sjc2-oc48-2.sfo1.above.net (208.184.232.54) 889.482 ms 2820.425 ms * 13 main1colo78-core1-oc48.sfo1.above.net (208.184.228.2) 1910.051 ms 2318.183 ms 1878.781 ms 14 above-gw.sfo1.collab.net (209.133.67.29) 2088.998 ms * 1759.875 ms 15 * * cr1-ge2-2-sfo.collab.net (64.125.132.9) 2269.453 ms 16 d2r1-ge2-1-sfo.collab.net (64.125.132.46) 2348.632 ms * 315.531 ms 17 64.125.132.231 (64.125.132.231) 284.888 ms 1204.667 ms 909.628 ms
Enhancement requests
Hi all. There are two enhancements I would like to see, both connected with the stuff it ignores on import and update: 1. cvs already ignores *.Z archives, so can it also be set to ignore *.bz2 and *.gz archives as well. 2. Can CVS be 'trained' to differentiate between directories and files for the various ignore entries? One obvious way to me would be to say that if the entry in the list of files to ignore ends with a / then that refers to a directory to be ignored, and any entry not ending with this character refers to a file. This would mean that to ignore something as both, it would need to be entered twice, once in each format. I will add that on looking at ignore.c I get the impression that something along these lines has already been a\dded, but just doesn't work. Comments anybody? Best wishes from Riley. ___ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
