pserver: cvs edit with a notify file, and cvs status fail
I have more problems after switching to pserver from NFS. The notify file now looks like: ALL echo error : %s is editing the file. If a user attempts to cvs edit a file being edited by another user, the system seem goes into a weird state and even a cvs status fails: % cvs edit file1.txt user1 is editing the file. cvs edit: dying gasps from server1 unexpected % cvs unedit file1.txt user1 is editing the file. cvs unedit: dying gasps from server1 unexpected % cvs status user1 is editing the file. cvs status: dying gasps from guinness unexpected Any idea why cvs status isn't returning what it should?? I can run cvs status in other directories Martin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
I thank everyone who have send me the answers, but I still don't know, how to get to know, what I want to know. Is there a simple way, how to inform the other users about my commit. I'd like the other users to get email, that contain names of the commit files and who who were they commited. To achieve this this I'd prefer 'notify' file, that will run extern mailing program (in my case 'postie.exe', that I found on internet). I'd like use the 'notify' file for every user to choose whether to receive email notification or not (with help Watch add command). If it is possible, please give me advice. Minutely, if you can. I'd be very obliged to you. P.S. I supposed, that I only write one line to 'notify' file to right working on NT server. For examle: ALL postie -to:%s -msg:"Parameters, which I ask you" Is possible it? Tomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
Tomás Velek wrote: I thank everyone who have send me the answers, but I still don't know, how to get to know, what I want to know. Is there a simple way, how to inform the other users about my commit. I'd like the other users to get email, that contain names of the commit files and who who were they commited. To achieve this this I'd prefer 'notify' file, that will run extern mailing program (in my case 'postie.exe', that I found on internet). I'd like use the 'notify' file for every user to choose whether to receive email notification or not (with help Watch add command). If it is possible, please give me advice. Minutely, if you can. I'd be very obliged to you. P.S. I supposed, that I only write one line to 'notify' file to right working on NT server. For examle: ALL postie -to:%s -msg:"Parameters, which I ask you" Is possible it? Tomas If you have a cm account (or even a dummy account that can be controlled by cm if cm does checkins) have that account do a cvs watch add -a commit at the head of your tree and then change your 'notify' file to ALL postie -to:ALL_MY_PROJECT -msg:"Parameters, which I ask you" where ALL_MY_PROJECT is an alias on your mail host to everyone in your group, this will force it out to everyone. My preference though has always been to leave the -to: as -to:%s and request that everyone on the project run cvs watch add -a commit in the directories they may be changing, that way if it is a big project they are not getting hundreds of emails a day for directories that may/do not affect them. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
Laird Nelson wrote:
How about take a chapter out of the CGI/web book and shove all
parameters in url-encoded form on STDIN? Then people can use existing
code libraries/snippets to parse this string into name/value pairs.
Just like an HTTP POST form submission. Then you don't have to remember
which 2037 arguments to add to the script invocation in the *info file,
and the script's environment isn't filled up unless the script wants it
to be.
CGI data comes in on STDIN? Huh. I programmed them for a year or so using the Perl
libraries and never
realized that. Let's hear it for high-level languages. :)
So here's an example (the following would show up on stdin of the
commitinfo program, let's say):
dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever
Running this through a standard URL unescaper (perl -MCGI -e 'print
unescape("dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever");')
yields:
Hmm. Two things:
1) I think XML might still be preferable to CGI. It would provide a more expandable
way to encapsulate the
data. For example, even though the script was set up to handle a single directory at
a time, a change in
the CVS source (and perhaps a switch in a config file) could start passing data on
multiple directories
without changing the DTD and maybe not changing the hung script.
2) CGI or XML, it's also going to drastically increase the cost of entry of creating
a new script to hang
as I'm not familiar with any CGI or XML libraries written in/for Bourne shells. I
_do_think there is a
simple solution to this, which is to write a simple sourcable one ourselves and
install it into
$CVSROOT/CVSROOT. Then a minimal Bourne shell script that wanted to use any data
passed by CVS would look
something like (I'm using callbacks since I think it's more expandable):
#!/bin/sh
# an example commitinfo script
. some_access_functions
do_file()
{
if user_has_access checkin $repository $directory $file; then
:
else
exit 1
fi
}
. $CVSROOT/CVSROOT/get_data_and_run
I suppose get_data_and_run wouldn't have to use callback hooks, but I like that model
better.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
One woman has hurt you and you'll take it out on the rest of the world? You're
a coward and a weakling!
- Ingrid Bergman as Elsa, _Casablanca_
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
"Derek R. Price" wrote: Laird Nelson wrote: How about take a chapter out of the CGI/web book and shove all parameters in url-encoded form on STDIN? Then people can use existing CGI data comes in on STDIN? Huh. I programmed them for a year or so using the Perl libraries and never realized that. Let's hear it for high-level languages. :) BTW, for those with backwards compatibility concrens, there's an easy upgrade path - to use the new data transfer methods new hook files would be set up. Say, *info2 rather than *info. Then if the *info2 had a match for the directory, CVS could ignore the *info file. In five years or so the *info code could probably even be disabled. :) Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I predict future happiness for Americans if they can prevent the government from wasting the labors of the people under the pretense of taking care of them. - Thomas Jefferson ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
Tomas Velek wrote:
Hello,
I want to inform other about commit. To do it I use the "notify"
file and the external file, which send the informative mail to people
in "users" file. After commit all people receive the mail, it is
right. But this mail must contains the names of commited files and I
can not reach it.
In "loginfo" file is possible to use %{sVv} parameter, but it does
not work in "notify" file.
I need to solve it very necessarily, please help
I'm using WinNT server, clients Win9x with WinCVS 1.1b16
I've seen a few requests lately for this kind of thing so I thought
I would send out a reminder that there's a patch against 1.11 (NOT the
NT version) which provides some hooks to pass new information through
the *info files at
http://alumni.engin.umich.edu/~oberon/ccvs.newfmtstrings.1-11.diff .
Theres the same code plus a new *info hook for filtering an rcsinfo
template _before_ the user sees it in an editor at
http://alumni.engin.umich.edu/~oberon/ccvs.tmpltfilterinfo.final.diff ,
but it's incomplete. The filter is currently running on the client and
should be running on the server.
There have been a few discussions lately about this kind of thing as
well, including one that suggested always providing all available
information for a hook in environment variables, similar to CGI, but I'm
not sure now that this patch isn't a better solution since it should be
harder to accidentally fill up a child's environment memory since an
administrator could pare the args going to a script when they _didn't_
want all the data. Of course, maybe some sort of pipe to squirt all the
data through as XML would be even better than that but I'm not sure I
understand all the issues here.
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I will not say "Springfield" just to get applause.
I will not say "Springfield" just to get applause.
I will not say "Springfield" just to get applause...
- Bart Simpson on chalkboard, _The Simpsons_
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: notify file
"Derek R. Price" wrote:
There have been a few discussions lately about this kind of thing as
well, including one that suggested always providing all available
information for a hook in environment variables, similar to CGI, but I'm
not sure now that this patch isn't a better solution since it should be
harder to accidentally fill up a child's environment memory since an
administrator could pare the args going to a script when they _didn't_
want all the data. Of course, maybe some sort of pipe to squirt all the
data through as XML would be even better than that but I'm not sure I
understand all the issues here.
How about take a chapter out of the CGI/web book and shove all
parameters in url-encoded form on STDIN? Then people can use existing
code libraries/snippets to parse this string into name/value pairs.
Just like an HTTP POST form submission. Then you don't have to remember
which 2037 arguments to add to the script invocation in the *info file,
and the script's environment isn't filled up unless the script wants it
to be.
So here's an example (the following would show up on stdin of the
commitinfo program, let's say):
dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever
Running this through a standard URL unescaper (perl -MCGI -e 'print
unescape("dir=foofilespec=a%7c1.2%7c1.3%7cOLD_TAGfilespec=b%7c1.1%7c1.2%7cOLD_TAGcvsroot=wherever");')
yields:
dir=foofilespec=a|1.2|1.3|OLD_TAGfilespec=b|1.1|1.2|OLD_TAGcvsroot=wherever
...and running this through a standard webbish/libwww slicer and dicer
program you'd get (the following is my own syntax):
dir=foo
filespec=a|1.2|1.3|OLD_TAG, b|1.1|1.2|OLD_TAG
cvsroot=wherever
Or you could make the filespec syntax resemble the Entries file, if you
wanted. I've chosen filename|oldversion|newversion|stickytag
arbitrarily.
Cheers,
Laird
--
W: [EMAIL PROTECTED] / P: [EMAIL PROTECTED]
http://www.amherst.edu/~ljnelson/
Good, cheap, fast: pick two.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Parameters in notify file
Hello, I use "notify" file to notify others about commit. In this file is the line: ALL postie -host:10.10.10.99 -to:%s -from:[EMAIL PROTECTED] -s: \"CVS $USER\" -msg:\"CVS notification\" This command send the message to all users in "users" file, whenever commit was made. But I don't know a parameter, which contains information about names of commited files or modules (like parameter $USER for user name). I'm using WinCVS 1.1b16, server WinNT, clients Win9x Thanks for every help Tomas Velek ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
notify file in sandbox's CVS directory...
I have recently run into a rather odd instance of a notify file causing problems in the CVS directory of a users sandbox... What I would like to know is what might cause the creation of a notify file in a users sandbox and what it's purpose is... The problem started when a user was attempting to add files to the repository, the pserver was reporting a 'nothing known about...' error response. Pertinent version info: Client - jCVS 5.1.1, JRE1.2, win2K 2195, intel Server - Redhat Linux 6.1 (sort of =), cvs 1.10.8, pserver, intel The Notify file in CVSROOT is just comments, but watches are on for the project... The contents of the file are as follows: --- begin paste --- ESection_One.htmThu Apr 13 14:07:23 2000 GMT remote.via.jCVS ./FuncSpec/SectionOne/ --- end paste --- Is this a jCVS client issue, or does the c/s protocol require the creation of such files? Any help would be appreciated as in the future I would like to avoid whatever caused it... =) Scott -- Scott Sutherland National Computer Systems (319) 354-9200Measurement Services Division [EMAIL PROTECTED]Iowa City, Ia import my.standard.disclaimer.*;GO HAWKS!!!
Re: notify file in sandbox's CVS directory...
CVS/notify is created by "cvs commit" (when unediting), "cvs edit", "cvs release" (when unediting), and "cvs unedit". It's part of the client/server protocol. When using it in conjunction with "cvs add", it works fine under the normal rsh-connect client/server setup. I don't know how it behaves under pserver. Also, I don't know what'll happen in the following: cvs add file cvs edit file cvs rm file cvs ci # assuming other stuff has changed Although I do know that: cvs add file cvs edit file cvs rm file cvs unedit file will give you something like, "nothing known about..." I hope this provides enough to track down the problem. Noel PS One of my TODO's is to allow the editing and unediting of unknown files. Such a patch should fix the above problem(s). [EMAIL PROTECTED] on 2000.05.08 12:32:37 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: notify file in sandbox's CVS directory... I have recently run into a rather odd instance of a notify file causing problems in the CVS directory of a users sandbox... What I would like to know is what might cause the creation of a notify file in a users sandbox and what it's purpose is... The problem started when a user was attempting to add files to the repository, the pserver was reporting a 'nothing known about...' error response. Pertinent version info: Client - jCVS 5.1.1, JRE1.2, win2K 2195, intel Server - Redhat Linux 6.1 (sort of =), cvs 1.10.8, pserver, intel The Notify file in CVSROOT is just comments, but watches are on for the project... The contents of the file are as follows: --- begin paste --- ESection_One.htmThu Apr 13 14:07:23 2000 GMT remote.via.jCVS ./FuncSpec/SectionOne/ --- end paste --- Is this a jCVS client issue, or does the c/s protocol require the creation of such files? Any help would be appreciated as in the future I would like to avoid whatever caused it... =) Scott -- Scott Sutherland National Computer Systems (319) 354-9200Measurement Services Division [EMAIL PROTECTED]Iowa City, Ia import my.standard.disclaimer.*;GO HAWKS!!! 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.
