CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Date: Wed, 25 Oct 2000 16:38:53 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) Lenny Foner writes: Ah ha! This is -exactly- what the problem was. I have somewhat over 300 environment variables (printenv returns about 11K bytes), since I often point at useful parts of the filesystem with them. (Do aliases count as well? What else? Why isn't this -documented- anywhere? Why in the world is it -true-? Even in GNU products? Unheard-of!) Aliases don't count unless they're exported into the environment Well, this is tcsh, so there isn't really a distinction there... (they're usually not -- check your shell documentation for details). It probably is documented somewhere, but it can be hard to find; try the exec*, errno, and intro(2) man pages. It's a kernel limit so it's out of GNU's control -- many times there's a kernel configuration variable to adjust it, but I don't know any details for HP-UX. Okay, I have -no- idea why the kernel cares about any of this. I had the impression that all of this was user-space stuff. I guess that exec and friends are passing the information to the newly-started process in ways I wasn't expecting, and it's probably time I took a closer look at them---though this is really a side-issue here. If you only use your variables in interactive shell commands (which it sounds like you do) there's no reason for them to be in the environment -- just set them and don't export them (or use set instead of setenv if you're a csh user). I'm reasonably sure I had reasons for these being setenvs and not sets, having to do probably w/the ability for Emacs to inherit them from the shell I started it from, but I don't recall. It's been a very long time (years) since I set up the skeleton of what's become my environment, and there may well be multiple reasons. (And I know that some of them are deliberate set/setenv based on whether or not I want them bleeding into subshells, etc. It's gotten quite complicated over the years.) Anyway, changing it just for the sake of making a marginal case in CVS' test suite work is unlikely to happen... [ . . . ] environment, or something. Note that "env -i make check" in the src dir worked, but not in the toplevel dir (where it would normally be run), because for whatever reason the line in the makefile after configuration only has an explicit path for some binaries: That's because those binaries live in different places on different systems but they're almost always on the user's path. And that's what makes it tricky to prune the environment automatically -- there are a number of environment variables that you *do* want to keep, but only *you* know for sure what they are. (Although PATH is a pretty good bet!) [ . . . ] Well... my $PATH is actually set using "set path", not "setenv PATH", which means that "env -i echo $PATH" actually returns a non-null path. (But I think this is treated very specially by tcsh; again, I don't recall the details.) Presumably, the fact that "env -i echo $PATH" is non-null explains, in part, why "make check" while in cvs-1.11/src worked, but in that case, I don't understand why "env -i make check" -at toplevel- (e.g., not inside src) then blew up with what looks like a missing-PATH problem. I haven't debugged this at all, though. I have a suspicion it may have to do w/recursive calls to make. But anyway, for "make check" alone, wouldn't it make sense to just zero the environment? I can't see why it would depend on some random set of user EV's---that seems extremely undisciplined for a test suite. And it certainly worked fine for -me- with a zeroed environment, not that this tells us much about other systems. (Not to mention that, if weird EV's -are- used, wouldn't it be a -really good idea- to have the test suite explicitly know what they are? After all, if you don't do this, then you run the risk of the suite working fine in the builder/tester's environment, but CVS malfunctioning in other users' environments, which is a disaster that's also problematic to debug. Better that it blow up while being built, so the builder knows to adjust all users' environments if necessary, rather than having it possibly be weird only for some of the users.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
winCVS problem
Hi. I ve got WinCVS 1.1 installed as a client on NT and a cvs linux server. When I choose the menu command: Query - Graph Selection an NT application error window pops up saying smth like : "instruction 0x6c371351 uses memory address 0x0004. Memory cannot be read" Why is this happening? How can I remedy? Thanx
tagging files and certain whole directories in a module
Hi! I want to tag certain files and some whole directories under a module with the same tag. These files will later be exported to a release directory. If I have: Module |_dir1 |_dir2 | |_dir3 How can i tag all files in dir1? The tagging is recursive and will affect dir2 as well, right? /Patrik ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT or username in TCL
On Wed, 25 Oct 2000, "Thomas" == Thomas Olausson wrote: Thomas I'm trying to write a simple tcl script to echo out the Thomas CVSROOT-variable or better yet, the username the user has when Thomas logged in. Thomas It's set through the Admin-Preferences, so I can't get it Thomas from "env". I'm known for stating the obvious, so here goes... If this is inside a procedure, have you got a "global env" at the top of it? -- John Klassa / [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Unsubscribe
Hi : please, unsubscribe me form you mailing lists. Best regards -- Mustafa S. Al-Tamim Software Engineer IDS Software Systems Ramallah - Palestine Tel : + 972 2 2962155 ext. 131 Fax : + 972 2 2962151 Mail to : [EMAIL PROTECTED] Web : www.idsintl.com --
WinCVS problem
Hi! I am a new user to the WinCVS and am having the following trouble. Thefollowing is the information about versions: Linux 6.1 CVS version 1.10.6 WinCVS version 1.1b15I am seeing the following error on the binary files. cvs [server aborted]: can't stat PO_SWarch.doc: No such file or directoryThis problem OCCURS if the binary file is changed (i.e edited) and an attempt is made to commit the changes. Could you please helpme?Thanks.
Re: diff in commit message (was: Multiple-line log message)
Mike Castle wrote: On Tue, Oct 24, 2000 at 08:54:37PM +0200, Gerhard Sittig wrote: Does anyone know a method how to incorporate "cvs diff" into the "cvs commit" message and thus aid the committer with showing what has changed when he is asked to specify what he did and why? I would have to say, this is probably the ugliest idea I have ever seen. You really want to do this on a regular basis? Why? this information can ALWAYS be regenerated outside of the log message. I have to agree with Mike and Richard that your proposal seems to implement redundant functionality. I might put diffs in emails (a function there are scripts out there for already), but CVS will already allow me to view diffs and log messages so diffs in log messages seems like wasted space and useless clutter. Still, if you really want to try it, I have a patch built on top of my *info stuff that adds a tmpltfilterinfo file which works like loginfo and the rest but provides a filter script which accepts the text from rcsinfo on stdin and spits out the new text for the log message. It was originally intended to help integrate CVS with a BTS system but it's not perfect yet - it's still running on the client and doesn't quite work on NT. If this were to become popular I'd want the script execution moved to the server before integration with the main trunk. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- That liberty [is pure] which is to go to all, and not to the few or the rich alone. - Thomas Jefferson to H. Gates, 1798. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff in commit message (was: Multiple-line log message)
"Derek R. Price" wrote: Still, if you really want to try it, I have a patch built on top of my *info stuff that adds a tmpltfilterinfo file which works like loginfo and the rest but provides a filter script which accepts the text from rcsinfo on stdin and spits out the new text for the log message. It was originally intended to help integrate CVS with a BTS system but it's not perfect yet - it's still running on the client and doesn't quite work on NT. If this were to become popular I'd want the script execution moved to the server before integration with the main trunk. Whoops. Almost forgot the link. The diff is against 1.11: http://alumni.engin.umich.edu/~oberon/ccvs.tmpltfilter.final.diff Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- That liberty [is pure] which is to go to all, and not to the few or the rich alone. - Thomas Jefferson to H. Gates, 1798. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: tagging files and certain whole directories in a module
=?iso-8859-1?Q?Patrik_Sj=F6berg?= writes: How can i tag all files in dir1? The tagging is recursive and will affect dir2 as well, right? The -l option disables recursion. -Larry Jones Who, ME? Who?! Me?? WHO... Me?! Who, me??? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Lenny Foner writes: Okay, I have -no- idea why the kernel cares about any of this. I had the impression that all of this was user-space stuff. I guess that exec and friends are passing the information to the newly-started process in ways I wasn't expecting, and it's probably time I took a closer look at them---though this is really a side-issue here. Yes, this is way off-topic, but the short story is that the kernel only deals with one process at a time, so in order to copy the argument list and environment from the parent process to the child, it first copies it from the parent into a fixed-size temporary area in the kernel and then copies it from there to the child. It's been a very long time (years) since I set up the skeleton of what's become my environment, and there may well be multiple reasons. [...] Anyway, changing it just for the sake of making a marginal case in CVS' test suite work is unlikely to happen... Indeed. It's just that such a large environment is likely to cause you similar problems in other circumstances (``ls *'' in a large directory, for example), so I thought it was worth mentioning. Well... my $PATH is actually set using "set path", not "setenv PATH", which means that "env -i echo $PATH" actually returns a non-null path. That's a red herring (actually two red herrings). path is treated specially by most csh-like shells and automagically exported (as PATH) reguardless of how you set it. Also, the expansion of $PATH in the above command is done by the shell *before env even runs* -- running ``env -i printenv'' will show that the child process really does have an empty environment; running ``env -i tcsh -c set'' will show the default values tcsh makes up for things like path when they aren't inherited. But anyway, for "make check" alone, wouldn't it make sense to just zero the environment? I can't see why it would depend on some random set of user EV's---that seems extremely undisciplined for a test suite. They aren't random -- there's a well-defined set that the test suite uses if they're set: TESTDIR - the directory to run the tests in AWK - the awk program to use EXPR- the expr program to use ID - the id program to use TR - the tr program to use All of them have default values, but they are not appropriate for some people. (Note that these affect only the test suite itself, not CVS, so there's no danger of CVS working for the tester but not for the users based on their settings.) These variables exist because people (plural) have needed them -- you're the very first person to report a problem running the tests because of a large environment. -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
At 10:57 -0400 10/26/00, Larry Jones wrote: They aren't random -- there's a well-defined set that the test suite uses if they're set: TESTDIR - the directory to run the tests in AWK - the awk program to use EXPR- the expr program to use ID - the id program to use TR - the tr program to use All of them have default values, but they are not appropriate for some people. (Note that these affect only the test suite itself, not CVS, so there's no danger of CVS working for the tester but not for the users based on their settings.) These variables exist because people (plural) have needed them -- you're the very first person to report a problem running the tests because of a large environment. Maybe it would be safer to clear the environment at the beginning of sanity.sh. This is what I have used in the past to clear out unwanted stuff inside of a script. #! /bin/sh for VAR in `set | /usr/bin/sed -e 's/=.*//'`; do case $VAR in PATH ) ;; IFS ) ;; SHELL ) ;; USER ) ;; PS1 ) ;; PS2 ) ;; MAILCHECK ) ;; OPTIND );; * ) unset $VAR; export $VAR;; esac done unset VAR PATH=/usr/bin export PATH Modify it as you see fit and put it at the beginning of sanity.sh. Fred -- == Fred Brehm, Sarnoff Corporation, [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Frederic Brehm writes: This is what I have used in the past to clear out unwanted stuff inside of a script. Unfortunately, unset isn't portable. I just don't see this as being a serious enough problem to worry about. -Larry Jones We don't ATTEND parties, we just CRASH 'em. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS 1.11 sanity.sh fails at multiroot-log-1 under HPUX 10.20
Unfortunately, unset isn't portable. I just don't see this as being a serious enough problem to worry about. Oh c'mon. A portable fix for a confusing problem area is very simple: env |sed -e 's/=.*'/=/' /tmp/clean$$ for V in PATH HOME TR AWK ... ; do eval "save$V=$V" done . /tmp/clean$$ for V in PATH HOME TR AWK ... do eval "$V=save$V ; export $V" done Save the env vars sanity cares about, then by definition you don't care what values the other env vars are. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVSROOT or username in TCL
I'm known for stating the obvious, so here goes... If this is inside a procedure, have you got a "global env" at the top of it? Yes, but that's only getting the environment variables in WinNT. That username there is seldomly the same as the one you're using in CVS. Also, you can have several CVSROOTs, with different usernames. Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
CVS in client/server configuration
We have been running CVS successfully in its default mode for some time. I would now like to add the ability to connect to the repository from a remote client . Here are my Q's: 1. Which is best and simplest way to go i.e. rsh, authentication, GSSAPI, kerberos? 2. How do I set-up the server? It is something like a deamon running on repository machine? 3. Would I be able to use the 'normal' CVS concurrently with the clent/server config.? Thanks for all your help. -Fahim ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS in client/server configuration
[EMAIL PROTECTED] on 2000.10.26 13:54:19 We have been running CVS successfully in its default mode for some time. I would now like to add the ability to connect to the repository from a remote client . Here are my Q's: 1. Which is best and simplest way to go i.e. rsh, authentication, GSSAPI, kerberos? "Best" is a subjective word. rsh is by far the simplest way to go. ssh is pretty simple, too. 2. How do I set-up the server? It is something like a deamon running on repository machine? Usually (always?) the CVS server doesn't run as a daemon. It'll run with each invocation of CVS from the client side. 3. Would I be able to use the 'normal' CVS concurrently with the clent/server config.? All you should have to do is have the clients set CVSROOT properly (eg CVSROOT=username@server:/path/to/cvsroot) and take care of how they can log into the server without having to supply a password (eg .rhosts or ssh-agent). Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
setting up cvs for the first time -- suggestions wanted
Hi. I am attempting to use cvs for the first time and would appreciate any advice anyone has to offer that might help. Here's my setup... cvs server: Mac OS X cvs client(s): Win2000 Pro Mac OS X comes with cvs installed. I installed WinCVS on the machine running W2K. As for configuring the software, I'm not quite shure what to do. Has anyone put together a similar setup? What resources are there that might help me get the system working? I'd appreciate any advice available. -- Matt Munz [EMAIL PROTECTED] --- FREE! The World's Best Email Address @email.com Reserve your name now at http://www.email.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS in client/server configuration
I think there're more security concerns with pserver than with an SSH configuration. I know there's been lots of debate over this in the past (but I don't know the details). Noel [EMAIL PROTECTED] on 2000.10.26 16:46:01 To: [EMAIL PROTECTED] cc: Subject: Re: CVS in client/server configuration Thanks Noel, I just realized that what I actually NEED is the pserver because I need to allow remote login from outside of firewall. Thanks for your help. -Fahim Noel L Yap wrote: [EMAIL PROTECTED] on 2000.10.26 13:54:19 We have been running CVS successfully in its default mode for some time. I would now like to add the ability to connect to the repository from a remote client . Here are my Q's: 1. Which is best and simplest way to go i.e. rsh, authentication, GSSAPI, kerberos? "Best" is a subjective word. rsh is by far the simplest way to go. ssh is pretty simple, too. 2. How do I set-up the server? It is something like a deamon running on repository machine? Usually (always?) the CVS server doesn't run as a daemon. It'll run with each invocation of CVS from the client side. 3. Would I be able to use the 'normal' CVS concurrently with the clent/server config.? All you should have to do is have the clients set CVSROOT properly (eg CVSROOT=username@server:/path/to/cvsroot) and take care of how they can log into the server without having to supply a password (eg .rhosts or ssh-agent). Noel This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff in commit message (was: Multiple-line log message)
On Tue, Oct 24, 2000 at 14:21 -0500, Richard J. Duncan wrote:
Does anyone know a method how to incorporate "cvs diff" into
the "cvs commit" message and thus aid the committer with
showing what has changed when he is asked to specify what he
did and why?
As a background: At the moment I employ a homegrown wrapper
script around RCS to catch the diff before invoking an editor
with the diff log and the "tell me why you did it" message.
[ ... ]
I think hacking the source is overkill.
Your locking problem can be solved by running diff with the -n
option (proceed without lock).
You pushed me in the right direction! Although -n means "don't
actually do it", I found out about the (general) -R option for
"the repo is on a ro medium". And since I'm used to feed back to
where I get something from, here's what I came up with until now
after a (very) little toying:
export CVSEDITOR=/path/to/cvscommiteditor.sh
export EDITOR=/whatever/you/are/used/to
#!/bin/sh
# - cvscommiteditor.sh --
FILE=$1
cvs -R diff | sed 's/^/CVS: /' $FILE
${EDITOR:-vi} "$@"
# - E O F ---
I'm still not sure if this $CVSEDITOR script will always get only
this one argument. But it looks like it was so.
The next step could be to fetch the list of involved files from
$FILE and draw the diff just over them. This would better
reflect what will be covered by commit. This probably would be
with a perl script extracting the "modified / added / removed"
(pretty printed) section. The only sorrow I could see arise is
when somebody has the Bright Idea(TM) to translate or beautify
the prefix strings and thus breaks recognition. It's already bad
enough when people think to know how wide my screen is (think of
80 char text in 80 char wide terminals in vi with "se nu" on).
Do you want to see the diff output to assist in typing the
"this is what I did" message?
Yes, exactly. I'm aware of the fact that commenting on what the
code next to the comment _does_ is somewhat pointless (the code
should be written in a way to make this clear already). Instead
the comment should give hints about what the code is trying to
_achieve_ and respect that the particular algorithm is just an
implementation detail and actually doesn't matter in the abstract
problem solution.
It's exactly the "what was done" against the "what was meant to
be done" thing. We don't change code for fun but to achieve
results, don't we? :)
On Thu, Oct 26, 2000 at 10:19 -0400, Derek R. Price wrote:
Mike Castle wrote:
On Tue, Oct 24, 2000 at 08:54:37PM +0200, Gerhard Sittig wrote:
Does anyone know a method how to incorporate "cvs diff"
into the "cvs commit" message and thus aid the committer
with showing what has changed when he is asked to specify
what he did and why?
I would have to say, this is probably the ugliest idea I have
ever seen. You really want to do this on a regular basis?
Why? this information can ALWAYS be regenerated outside of
the log message.
I have to agree with Mike and Richard that your proposal seems
to implement redundant functionality. I might put diffs in
emails (a function there are scripts out there for already),
but CVS will already allow me to view diffs and log messages so
diffs in log messages seems like wasted space and useless
clutter.
Umm, obviously I've been unclear there. :) Of course it doesn't
make much of a sense to put the diffs into the commit message. I
meant to get them somehow into the "template" the editor sees to
aid the user in his thinking "what was it that I did to the
code?". And yes, a wrapper could have done. But telling the
users to issue "cvs ci" as they are used to from everywhere and
can read in all the doc is easier than teaching them to specify
"mycvs ci" which is nonstandard and confusing. And yes, even
"missing" mycvs wrappers can be handled by doing "cvs diff; cvs
ci" -- but it always is extra work and can easily be thought
about and handled once and for all.
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
moving CVS tree
We will be moving our tree from a Solaris 2.6 server to the same OS Solaris 2.6 server but a different server name. Is there anything we need to be concerned with? Thanks, BB __ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs login failure
(Oops. Thought I had sent this off days ago... Sorry.)
Some interesting news, below. Good but puzzling.
On 18 Oct, Derek R. Price wrote:
[EMAIL PROTECTED] wrote:
I did a strings on the Windows cvs.exe and on /usr/bin/cvs on Linux,
and both have CVS_CLIENT_LOG, so I assume the facility works similarly
as in the source to cvs 1.10.8 that I have handy: it just opens
$CVS_CLIENT_LOG.in and $CVS_CLIENT_LOG.out and writes in there.
No, that's about it. I'm not sure what shell you are using, but in Bourne, Bash,
and
Korn, you need to export environment variables for a child process to see them:
Sure. That's why I said I "exported" CVS_CLIENT_LOG.
Whoops. Just checked myself and CVS doesn't start writing to the client log until
after authentication, probably for the obvious reasons, but it does work under both
Linux Windows in 1.11.
So wouldn't get any debug for the part that's going wrong, anyway.
Anyway, I'd say your options are compiling a debug version under Windows and
attempting to trace the failed attempt or figure out what the difference between
your
Windows Linux CVSROOT specs are, since the Linux version worked.
I'll admit that it seems difficult to see how to setup the cvs server
to be run from gdb. Hmm, maybe I could attach to it once it was
running...
Is LOGNAME set
differently on the two machines?
No.
Try a CVSROOT with no variables in it. CVS
shouldn't be filling anything into CVSROOT on either platform, so if the problem
lies
there you should be able to fix it on the command line.
I think that's a small red herring. I tried without a CVSROOT, using
the -d option, with the same result.
Also, try again to make sure that handy's IP address is the same regardless of which
machine you look it up on.
Handy is defunct; "mantovani" is the stand-in. There is an amd entry
so that /home/handy is the same as /home/mantovani. But our network is
solid and clean, and I'd be flabbergasted if mantovani's IP address
changed while the machine was running (the IP addresses are assigned
dynamically from a server).
And now for the good but puzzling news. It's now working.
Now, keep in mind that this all used to work when Handy was alive; and
failed when Mantovani replaced it. Both were running the same version
of Linux with the same versions of the same utilities installed.
Also involved is an old version of ssh compiled for Windows.
The problem only occurs if we don't explicitly specify the login id when
we make the ssh connection from the Windows box to the Linux CVS
server. The ssh login succeeds, but when we later try to cvs login,
the cvs server on the Linux box rejects the login with the message
"authentication failure".
The mechanism works like this - let me use Win to stand for the Windows
client and Lin for the Linux server:
On Win we do: ssh -L 2401:localhost:2401 Lin
I gather this makes a loopback connection on port 2401 on localhost
(Win), talking to a 2nd loopback ssh connection on port 2401 on Lin,
and because of our /etc/{services,inetd.conf} and pserver CVSROOT, cvs
talks via ssh.
With the ssh -l $LOGNAME it all works. Without the -l $LOGNAME we get
the "authentication failure" error when the windows user tries to cvs
login - *even though the ssh login works*.
Each user only has a single login id.
Puzzles are:
1) If the -l $LOGNAME is needed, why did it work at all previously?
2) How can the ssh login succeed but the cvs login fail? Where does the
cvs server get the login id from? The client? If so, how does the
ssh login id affect it?
I twigged to this after trying a new ssh compiled under U/Win 2.25,
which just happens to default to using "DOMAIN/$LOGNAME" as the login
id. This forced me to specify -l $LOGNAME to make even the ssh login
succeed. And after that, the cvs login worked.
So, we're happy that it's now working, but don't really understand what
went wrong, or why it now works.
luke
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
cvs diff -N doesn't work (at all)
Hi, I'm not the first person reporting this problem but my problem is slightly different. Other reports say that cvs diff -N generate bad diff files but for me it doesn't generate diff at all for the new-file. Example: I've a local repository of the cvs.cvshome.org, in that repository i create a new file (named newfile) with some crap inside. Then I run cvs diff -N: $ cvs diff -N ? newfile cvs server: Diffing . Index: FAQ === (etc...) And no trace of my newfile in the diffs. If I insist: $ cvs -t diff -N newfile cvs diff: notice: main loop with CVSROOT=:pserver:[EMAIL PROTECTED]:/home2/cvsroot - Sending file `newfile' to server cvs server: I know nothing about newfile (grr... stupid server) Thanks -- Fabrice Gautier [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
