Can you cvs diff by committer and date?
Someone just asked me if there was a way to do a cvs diff for a particular date of all the changes made by a particular user. It seemed a reasonable question in context (which was two developers committing a raft of independent changes each, over the same day). luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Please be careful: don't Cc: to cygwin
I just sent the same question to this list and to the cygwin mailing list (I'm subscribed to both, obviously). Don't Reply-All to that post. I was automatically marked as a spammer by sending one email to both lists, even though the problem could be either a cygwin one or a cvs one. I'd hate to think that a helpful reply to my query might get someone else blocked. I guess Cygwin (RedHat?) have a rather draconian policy in place. So be careful. For reference, here's the auto-reply I got from Cygwin. luke From: [EMAIL PROTECTED] Subject: failure notice Date: 16 Mar 2004 01:12:05 - To: [EMAIL PROTECTED] Hi. This is the qmail-send program at sources.redhat.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. <[EMAIL PROTECTED]>: Your message was sent to both the mailing list and a project cvs list. If you are not a "spammer", we apologize for the inconvenience. You can add yourself to the cygwin.com "global allow list" by sending email *from*the*blocked*email*address* to: [EMAIL PROTECTED] For certain types of blocks, this will enable you to send email without being subjected to further spam blocking. This will not allow you to post to a list if you have been explicitly blocked, if you are posting an off-topic message, if you are sending an attachment that looks like a virus, etc. Contact [EMAIL PROTECTED] if you have questions about this. (#5.7.2) --- Enclosed are the original headers of the message. From: [EMAIL PROTECTED] Subject: cvs problem under cygwin, cvs documentation Date: Tue, 16 Mar 2004 12:11:58 +1100 (EST) To: [EMAIL PROTECTED], [EMAIL PROTECTED] (Body suppressed) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs problem under cygwin, cvs documentation
I wrote: > Although we have a moderately good workaround (an old version of cvs > compiled up), we have a long-standing problem with cvs in Cygwin that > I'm looking into finally. We get responses like: In case you didn't see my other warning post, I'll repeat it here: I just sent the same question to this list and to the cygwin mailing list (I'm subscribed to both, obviously). Don't Reply-All to that post. I was automatically marked as a spammer by sending one email to both lists, even though the problem could be either a cygwin one or a cvs one. I'd hate to think that a helpful reply to my query might get someone else blocked. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs problem under cygwin, cvs documentation
Although we have a moderately good workaround (an old version of cvs compiled up), we have a long-standing problem with cvs in Cygwin that I'm looking into finally. We get responses like: $ /usr/bin/cvs update [EMAIL PROTECTED]'s password: ' from cvs serverng: unrecognized response `ok cvs [update aborted]: received interrupt signal Killed by signal 2. Which of course is newline conversion problems: $ /usr/bin/cvs update 2>&1 | od -c [EMAIL PROTECTED]'s password: 000 c v s u p d a t e : w a r n 020 i n g : u n r e c o g n i z e 040 d r e s p o n s e ` o k \r ' 060 f r o m c v s s e r v e r A message from 2002 to the cvs mailing list suggested using the access method :server: instead of the default :ext:. I added this to CVSROOT like so: CVSROOT=:server:cvs.research.canon.com.au:/u/cvs but that had no effect on existing checkouts because of the existing CVS/Root file, but after editing that to insert the :server: at the front: $ cat CVS/Root :server:cvs.research.canon.com.au:/u/cvs I got this response: $ /usr/bin/cvs update cvs [update aborted]: the :server: access method is not supported by this port of CVS Any suggestions? I notice that none of the :ext: or :server: stuff is written up in the CVS man page. I'll have a read through the FAQ. Erk. Our local copy is 1993. Erk. The CVS FAQ at http://ccvs.cvshome.org/fom//cache/1.html doesn't appear to be available as a single file, and doesn't seem to be as comprehensive as the old FAQ anyway. http://www.cvshome.org/docs/#s3 points at the old CVS site, but the good FAQ doesn't exist there either. Oh well. I suppose it's really a Cygwin problem, because a version someone once compiled up here is okay. I see it's just a client version, not a client/server version. Working version of cvs under Windows/Cygwin: $ /opt/bin/cvs --version Concurrent Versions System (CVS) 1.10 `Halibut' (client) Copyright (c) 1989-1998 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Broken version of cvs under Windows/Cygwin: $ /usr/bin/cvs --version Concurrent Versions System (CVS) 1.11.6 (client/server) Copyright (c) 1989-2003 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors CVS may be copied only under the terms of the GNU General Public License, a copy of which can be found with the CVS distribution kit. Specify the --help option for further information about CVS Ah, one other difference is that our /opt/bin/cvs version does not complain about CVSROOT starting with ":server:", so the real question may be: why doesn't the Cygwin version include that? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout a file revision to stdout?
On 16 Mar, To: [EMAIL PROTECTED] wrote: > Is there any way to checkout a specific revision of a file to standard > output, rather than creating a file? Apologies for answering my own question. I see the -p option does what I want. -p Pipe the files retrieved from the repository to standard output, rather than writing them in the current directory. Available with the checkout and update commands. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Checkout a file revision to stdout?
Is there any way to checkout a specific revision of a file to standard output, rather than creating a file? The real reason for wanting to do this is to find which revision of a file a particular piece of text first appeared. I wrote a script called rcsgrep a long time ago that checked out files on the main trunk only directly from the ,v file in the archive, and grepped through each one in turn. So I could use that. I just wondered if there was a better way. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and gdbm?
On 5 Sep, Max Bowsher wrote: > > Is there any further info on configuring CVS to use gdbm? Especially, > > benchmarks? > > No benchmarks, but the "appropriate edits" to use gdbm exist in the Cygwin > package of cvs. Interesting. That would explain the recent Cygwin announcement of the need to use the conversion program following the recent changes to gdbm. So I take it that there's some benefit seen in using gdbm; presumably related to performance? But that for some reason it's not considered the right choice to make it the default for Unix. (Perhaps because Unix people prefer to use plain text where possible, to leverage from all those existing plain text utilities.) luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Diff treats files as text after they have been flagged -kb
On 5 Sep, Jack Dodds wrote: > However this leaves the original .WPJ and .TGT "text" files. I > used cvs admin to attach the -kb flag to all the .WPJ and .TGT > files both in the repository and the sandbox, expecting this > to fix the problem. (This lead to some CR/LF problems when > old versions of the .WPJ and .TGT files were checked out, but > I was able to write a utility to fix that.) > > In spite of flagging all the old .WPJ and .TGT files -kb, diff > still compares the files as if they were text files. > > Any suggestions as to how to fix this? I could of course > export the whole project and import it into a completely > new repository, but I would lose the history in the present > repository. I thought the admin -kb only affected the repository, *not* your checkout. If so it would explain your observation. What happens in a fresh checkout? My theory is that the files will be properly seen as binary files in that case: an easy test. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff, proposal for change
On 5 Sep, Greg A. Woods wrote: > > cvs already supports binary files to the extent of offering > > -kb. > > "CVS supports binary files"?!?!?!? No, I don't think so. The '-kb' > "sticky flag" is just a terribly bad hack that gets more people into > more trouble with CVS than you could ever imagine because it gets > mis-interpreted as doing what you think it does. It was not intended > for that purpose at all and it does not work the way you think it does. > > DO NOT try to store binary files in CVS. We are currently storing gigabytes of binary data files in our CVS repository along with lots of text data. We have found that if you remember to cvs add -kb from Windows (mandatory) or Unix (recommended), or to mark the files as binary after check-in under Unix *before* the first-ever modification is made, it can cope. At the cost of performance penalties. But reading the above I'm wondering whether there's some other danger that we're unaware of, that would make us change our current methods. I've read the FAQ section on binary files, and found nothing there that I/we weren't already aware of. Regards, luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS and gdbm?
The CVS FAQ says: By default, the `modules' file behaves as described above. If the modules file is very large, storing it as a flat text file may make looking up modules slow (I'm not sure whether this is as much of a concern now as when CVS first evolved this feature; I haven't seen benchmarks). Therefore, by making appropriate edits to the CVS source code one can store the modules file in a database which implements the ndbm interface, such as Berkeley db or GDBM. If this option is in use, then the modules database will be stored in the files `modules.db', `modules.pag', and/or `modules.dir'. Is there any further info on configuring CVS to use gdbm? Especially, benchmarks? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs diff, proposal for change
On 3 Sep, Terrence Enger wrote: > (*) "cvs diff" and "cvs rdiff" accept optional arguments > --filter1=, --filter2=, > --filter-both=. Allow Unix-style pipelining of simple commands to extend diff functionality? Excellent idea! luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why can't root check in files?
[This thread is about using cvs on files in /etc.] On 18 Oct, Kaz Kylheku wrote: > Also I disagree about the ``as is'' to begin with. The file metadata such > as permissions will not be properly versioned if the sandbox is made > to serve as the deployment directory. Basically, the sandbox file > will inherit its permissions from the corresponding ,v file in > the repository. Changing the permissions on a ,v will affect all versions > simultaneously, so the idea of recoverable configuration---which is > the central concept in version control---goes out the window. No, the file metadata is recorded in a separate metadata file which is itself under revision control. So, none of the points above apply. The only reason for giving the same permission and ownership to the ,v files is to give them the same level of security as the live files. > You will get better version control if you just edit your /etc directory > in place and do daily backups of it instead of fussing about with CVS. No, due to the above point. Unless you'd also claim that you'd get better revision control of source code by doing the same thing, and not using cvs at all! I think we'll just have to agree to differ. I've been using it for a month now, on several systems, and it's working very well and exactly as I hoped, and causing no problems. Once I've written up a good man page, I'll make it available for anyone who wants it. Thanks for the discussion, and best regards, luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
Mike Castle wrote: > On Fri, Oct 13, 2000 at 02:42:15PM +1100, Luke Kendall wrote: > > But the CVS archive isn't working for the Windows machines anymore; > > any attempt to do a cvs login gets the error below: > > > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > > Started ssh, so now you need to cvs login: > > (Logging in to luke@localhost) > > CVS password: > > cvs [login aborted]: authorization failed: server localhost rejected access > > Wait. You are using ssh to log back into the Windows machine? > (luke@localhost) That doesn't seem to make a lot of sense. Or were you > just obscurring information there? No, that's exactly what I used; it's the output from a script wrapped around it that only starts an ssh connection to the cvs server machine if there isn't already one running, and also sets some environment variables. Fundamentally it does this: wterm sh -c "ssh -l $LOGNAME -L 2401:localhost:2401 mantovani" & CVSROOT=":pserver:$LOGNAME@localhost:/home/mantovani/cvs-archive" CVS_SERVER="/usr/bin/cvs" export CVS_SERVER cvs login This means that at localhost on the client, and on localhost on the server, an ssh connection to port 2401 is made. So all cvs communications are sent via ssh. We use this because we're working on a clean room project; it just happens to be the same system we use if working off site. > Why don't you use :ext:luke@linuxhost:/home/mantovani/cvs-archive > > And set CVS_RSH to ssh. See above. Plus, it used to work until we changed the CVS server from one Linux machine to another. And this way still works when talking to another server serving another CVS archive. A very significant fact: when logged into the cvs server, if we use CVSROOT=":pserver:$LOGNAME@localhost:/home/mantovani/cvs-archive" cvs login fails there! Doing a trace of it, all we see is the server sending the message "I HATE YOU". So the password validation appears to be failing. In summary: I think we're using ssh for good reasons; it used to work; changing from one Linux machine to another (and re-doing the config) stopped it working; we can still use the technique to talk to another server serving another CVS archive. Any hints about how we diagnose this? Does cvs provide any verbose logging or debug mode? AFAIK, cvs login takes no options. My next step otherwise will be to modify the cvs source to generate some information to trace what's going on. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
> > Luke Kendall writes: > > > > CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive > > Started ssh, so now you need to cvs login: > > (Logging in to luke@localhost) > > CVS password: > > cvs [login aborted]: authorization failed: server localhost rejected access > > > > Is there any way to find out why the cvs client (or is it the server?) > > rejected the login? Is there any kind of logging information that can be > > examined? > > Like the message says, it's the server that rejected the login. When > you get just that message with no additional information, it means that > either the user exists but the password didn't match, If it was using the user CISRA/luke instead of luke (i.e. if for some reason it was insisting on using the Windows domain name plus user name), the password would fail to match. Is there any way to force it to use a specific user name? > or the repository > you specified does not match one of the --allow-root= arguments > specified for the server (in /etc/inetd.conf, presumably). No, it looks like: cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs --allow-root=/home/handy/cvs-archive pserver Although the machine "handy" died, and was replaced by "mantovani", the auto mounter has been adjusted to pretend matovani is handy. We also tried explicitly changing the inetd.conf to refer to mantovani, and killed inetd processes, but it made no difference. :-( > The current > development version now has an additional message for the latter case, > so you'll be able to tell which it is in the future. Sounds helpful. But are there any log messages we can use to find the exact username it was using? I'm suspicious of that. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
About the cvs login failures
I should have added that the Windows machine can access other CVS archives using the same pserver method - the cvs login command to the archive on another machine (a Solaris machine), works fine. It's just the stand-in Linux machine that the Windows clients can't cvs login to. luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs login failure
We had a Linux machine hosting a secure CVS archive, for some Windows and Linux development. Then the Linux PC died. Fortunately, the CVS archive was on its own drive, so we just put it into a 2nd Linux machine, and re-did all the ssh and inetd configuration. The Windows machines access the CVS archive via the pserver method, using ssh. The Linux machines just set CVSROOT to use the archive directory (it's auto-mounted). But the CVS archive isn't working for the Windows machines anymore; any attempt to do a cvs login gets the error below: CVSROOT set to :pserver:luke@localhost:/home/mantovani/cvs-archive Started ssh, so now you need to cvs login: (Logging in to luke@localhost) CVS password: cvs [login aborted]: authorization failed: server localhost rejected access Is there any way to find out why the cvs client (or is it the server?) rejected the login? Is there any kind of logging information that can be examined? One fact that is probably a red herring, is that the window in which the ssh connection to the CVS server is made, displays errors like: $ DUPRE.: Connection to port 2401 forwarding to localhost:2401 requested. Address 127.0.0.1 maps to dupre, but this does not map back to the address - POSSIBLE BREAKIN ATTEMPT! But we used to get errors like this with the now-dead Linux PC, and everything worked fine. We're using cvs version 1.10.6 under Red Hat Linux 6.1, and the cvs client version is 1.10. The only change was the replacement of one Linux PC with another. Any suggestions? luke ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
