RE: loginfo log messages
Daniel,
Why do you need the at the end of the loginfo line?
I did a simple test with
DEFAULT cat
and it works, i.e. the log message is displayed in the shell
where i do the commit, but
DEFAULT cat
does not work, i.e. nothing is displayed in the shell.
/Ludde
Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com
-Original Message-
From: Grisinger, Daniel (MAN-Golden) [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 00:35
To: 'Larry Jones'
Cc: '[EMAIL PROTECTED]'
Subject: RE: loginfo log messages
Larry Jones [EMAIL PROTECTED] writes:
Grisinger, Daniel (MAN-Golden) writes:
Larry Jones [EMAIL PROTECTED] writes:
I think you've confused info-cvs with a perl list.
Well, no, I haven't. The perl is correct, it simply reads
from STDIN. The
problem is unquestionably a cvs issue. But since that's
the attitude here's
the
shell code that also doesn't work.
Are you *sure* the perl is correct?
Yes. Running it outside of CVS results in STDIN being echoed
back out.
Have you checked to see if your script is executing at all?
It is. The script mails a summary of changes out to the
other developers on
my team. This summary is complete except for the logmsg
field. I'm getting
the rest of the params (repository directory, file changed,
old rev, new
rev)
passed through in ARGV. There just isn't anything on STDIN
to read from
(which
is where I expected to find the data, based on the CVS manual).
What is the exact content of your $CVSROOT/CVSROOT/loginfo file?
DEFAULT
(/home/cvsuser/cvs-scripts/cvs-mail-checkin-notifications %{sVv}
/home/cvsuser/cvslogs/commit-mailer.log 21)
I've also tried:
DEFAULT (sleep 3;
/home/cvsuser/cvs-scripts/cvs-mail-checkin-notifications
%{sVv} /home/cvsuser/cvslogs/commit-mailer.log 21)
I removed the call to sleep(1), because I thought that maybe it was
eating STDIN before my script could get at it. The current
script sleeps
for a bit to give CVS time to clear locks (since it calls cvs
internally).
There are no other entries in the loginfo file besides the
DEFAULT. (If
my company's dumb windows mail client wrapped that line, be
assured that
it actually appears as a single line in the loginfo file.)
What is the exact command you used for the commit and what
was the exact
output?
$ cvs commit -m 'test commit' scrubber.c
Checking in scrubber.c;
/home/cvsuser/repository/is_devel/src/scrubsys/scrubber.c,v
-- scrubber.c
new revision: 1.17; previous revision: 1.16
done
$
Nothing is coming on STDIN, which is what I expected. I
could always call
cvs log from within the script and parse the latest log
message out of it,
but the manual suggests that I should be seeing the log
message coming in
on my standard input.
Thanks.
daniel
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Commit inconsistency: Up-to-date check did not fail though itsho uld have !
- User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. User B is an idiot for not performing a commit over the entire tree which is affected by his change, and for having unrealistic expectations on what a single-file commit ought to do. Just go to the highest relevant directory and type ``cvs ci'' with no arguments, or at most a -m to specify the message. Hmm, this is interesting. I have always been (and still am) of the opinion that one should always commit individual files, and never ever do a 'cvs commit' on the top level of a module. Why? Because top level commits usually create poor log messages (same for all files), and because it makes it far too easy to commit files that you have just made temporary modifications to (e.g. changing a make file to compile with debug flags) that you really don't want to commit at all. Oh well, I guess I must be a total idiot then... /Ludde Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Removing a branch
A simple question - is it possible to remove a branch? I have tried: cvs rtag -d branch_name module_name cvs rtag -b -d branch_name module_name But the branch is not removed. For each file I get the message: cvs rtag: Not removing branch tag `branch_name' from `/shared/cvs/module_name/file_name'. /Ludde Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: TAG and file removing
Have you tried to check out the tagged version of the module? I'm sure you will find it contains the removed file, just as you want. (That's what the Attic is for - to store files that are not in the head revision of the trunk, so that they can still be included when a tagged version of the module is check out.) Regards, /Ludde Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com -Original Message- From: Jean-Baptiste BRIAUD [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 29, 2003 15:36 To: [EMAIL PROTECTED] Subject: TAG and file removing Hello, A developper had removed a file in a tagged module. How is it possible ? Am I missing something ? I thought a tag in a module was like a picture of all files revision number of the module, so you can later checkout the module with the tag name. But if it's possible to remove file (remove and commit !!! It's really in the Attic folder on server side) Then, how will I be able to checkout module with tag name ? The resulting checkedout module will not reflect the one I had when I tagged it ! I thought you had to create branch in order to modify a tagged module ... Help ! I'm disapointed !! ( There was some threads in the archive, but the answers was not clear enought. = is it OK or not to remove file from client side in a taged module ? != removng a tag. I don't speak of removing a tag. ) Thanks CVS users ! __ Jean-Baptiste BRIAUDSysdeo Software engineer www.sysdeo.com www.eclipsetotale.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Cvs message after every command:Socket operation on non-socket
This happens to me too, but only on Windows (running a 1.11.4 client on Windows against a 1.11.4 server on a UNIX (Solaris) machine, with the :server: access method). I don't get it when running a 1.11 Windows client against the same server, which may indicate that the problem is with the 1.11.4 Windows client. Regards, /Ludvig Borgne Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com -Original Message- From: Jeeva Sarma [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 21, 2003 20:02 To: [EMAIL PROTECTED] Subject: Cvs message after every command:Socket operation on non-socket Hi I have just upgraded both my cvs client and server to 1.11.4. Since then, I see the following message after every cvs command is executed. CVS.EXE commit: reading from p6dbu.mbtv.com: Socket operation on non-socket I see this after every command: update, co, commit, add. The command is executed properly though. Can anyone tell me what this message means and what I should do to not see it? TIA, Jeeva Sarma __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Max-dotdot not changed by -d option
Hi, Just joined this mailing list to be able to ask you this... Using client/server CVS, when I do cvs checkout -d ../x x I get an error message cvs server: protocol error: `../x' contains more leading .. cvs [server aborted]: than the 0 which Max-dotdot specified I have looked through the FAQ and searched through the mailing list archives, but not found anything that tells me if this is due to a bug, or if it is a security feature. I have had a look in the code (client.c), and I see that Max- dotdot is set according the number of levels in the arguments (x here) only, not according to the number of levels in the directory given by the -d option (../x). So it's easy to see why Max-dotdot is 0, which is why I get the error message. Still, I don't understand if it's a bug or a feature. Maybe someone out there can tell me? Regards, /Ludde Ludvig Borgne, Prover Technology AB, [EMAIL PROTECTED], www.prover.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
