Re: HOWTO: debug pserver

[Larry Jones]

Peschko, Edward writes:
> 
> 3) run the cvs command that you want to debug or trace with CVS_CLIENT_LOG, 
> against the copied cvs tree. Note that you need to use a cvs tree with pserver,
> not :ext.

That is not true, *any* client/server mode will work.  I usually use
:fork:.

> Caveats: Note that follow-fork-mode child does *not* work, nor does debugging parent
> code after the fork (it causes an ABRT signal ). Note also that there will be a 
> disconnect
> between the debugging and the real world because the above will only output what 
> happens
> to stderr, and not actually apply any of the changes to the cvs tree.

Not so -- you're running the server, it will do everything it usually
does.  If you send it commands that affect the repository, it will
update the repostitory.

> I'm not sure how you'd do the above in daemon mode,

If you really need to do that, you should already know how.  :-) One
approach is to have inetd run a shell script that sets $CVS_SERVER_SLEEP
before invoking CVS to give you time to connect to the child process.

> or how you can use the output from the server, and redirect it
> to a cvs client call (in gdb). Perhaps someone could elaborate?

Similar to the above, if you set $CVS_SERVER_SLEEP and then run using
the :fork: method, that will give you a normal client/server setup and
give you time to attach to the server child process with a debugger.

-Larry Jones

I don't think math is a science, I think it's a religion. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is it possible to make CVS send email notification with changesintroduced into committed file version

[Isaac Claymore]

On Thu, Jun 05, 2003 at 08:38:42AM -0400, Uri Abramov wrote:
> Hi, 
> 
> I have two questions :
> 
> 1. Is it possible to add new administrative file under CVSROOT in such way that it 
> would be treated by cvs as it treads it's native administrative files. I mean always 
> keep in repository  file,v and file. If it' possible how can I do it ?
> 
> 2. I'd like CVS send email to every developer who works on certain project when 
> someone from them remove, add or change file, and more than that I'd like to send in 
> the email the diff between old and new versions of a file. Does anybody knows how it 
> can be done?
> If yes How ?

google activitymail 
 
> Thanks in advance.
> Uri
> 
> 
> 
> ___
> Info-cvs mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/info-cvs

-- 

Isaac Claymore  /"\ASCII Ribbon Campaign
Dawning Inc.\ /Respect for open standards
Beijing, China   X No HTML/RTF in email
http://www.dawning.com.cn   / \No M$ Word docs in email


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Larry Jones]

Kaz Kylheku writes:
> 
> This is as it should be. The TYPES file represents the project's
> policy; some random user command should not override that policy. If we
> don't want .exe files in the repository, the add command should defend
> that decision for us, even if weakly.

I happen to disagree, strongly.  Repositories are not homogeneous -- you
may not want executables in your module, but I want them in mine.  And
file name suffixes are not unique and reliable indicators of a file's
type.  My .doc files are plain text, thank you very much, not MS Word
documents.  There's nothing I hate more than software that thinks it
knows more than I do and refuses to let me do what I want to do.

-Larry Jones

Somebody's always running my life.  I never get to do what I want to do.
-- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is it possible to make CVS send email notification with changes

[Larry Jones]

Uri Abramov writes [in very long lines]:
> 
> 1. Is it possible to add new administrative file under CVSROOT in such
> way that it would be treated by cvs as it treads it's native
> administrative files. I mean always keep in repository  file,v and file.
> If it' possible how can I do it ?



> 2. I'd like CVS send email to every developer who works on certain
> project when someone from them remove, add or change file, and more than
> that I'd like to send in the email the diff between old and new versions
> of a file. Does anybody knows how it can be done?



Also see the example script in contrib/log -- it runs status rather than
diff, but the principle is the same.

-Larry Jones

I obey the letter of the law, if not the spirit. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored...

[Eric Siegerman]

On Wed, Jun 04, 2003 at 02:19:44PM -0700, Peschko, Edward wrote:
> [ Larry Jones wrote:]
> > Damn straight. If you want software that thinks it knows more than you
> > etc...
> 
> But that goes contrary to the dictum "there's more than one way to do it".

Umm, you've got the wrong Larry :-)

No way is that expression generally accepted computing wisdom.
It's just a summary of the philosophy (to use the term rather
loosely) behind Perl's design (or rather, lack thereof).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]
|  |  /
When I came back around from the dark side, there in front of me would
be the landing area where the crew was, and the Earth, all in the view
of my window. I couldn't help but think that there in front of me was
all of humanity, except me.
- Michael Collins, Apollo 11 Command Module Pilot



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is it possible to make CVS send email notification withchanges introduced into committed file version

[Jenn Vesperman]

On Thu, 2003-06-05 at 22:38, Uri Abramov wrote:
> Hi, 
> 
> I have two questions :
> 
> 1. Is it possible to add new administrative file under CVSROOT in such way that it 
> would be treated by cvs as it treads it's native administrative files. I mean always 
> keep in repository  file,v and file. If it' possible how can I do it ?

Yes. There's a file called .. I think it's called checkoutlist. One
moment...

... yes. Checkoutlist. Look for the node 'checkoutlist' in info cvs,
it's under 'administrative files'.

Simply add the filename (and maybe path from CVSROOT) in the
'checkoutlist' file in CVSROOT, and it will be treated as an
administrative file.


> 2. I'd like CVS send email to every developer who works on certain project when 
> someone from them remove, add or change file, and more than that I'd like to send in 
> the email the diff between old and new versions of a file. Does anybody knows how it 
> can be done?
> If yes How ?

You can use the cvs watch, or the 'loginfo' file, to do this during
commits. See the 'notify' administrative file and the 'watch' commands
in 'info cvs', or the 'loginfo' administrative file.

You would include 'cvs diff' as part of the command run from 'notify' or
'loginfo'. Pipe the results of the diff into an email, and send the
email. (Make sure you background the command, to prevent deadlocks.)




Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.
   My book 'Essential CVS': published by O'Reilly in June 2003.
[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Frederic Brehm]

At 10:08 AM 6/5/2003, Larry Jones wrote:
There's nothing I hate more than software that thinks it
knows more than I do and refuses to let me do what I want to do.
The principal of least surprises should be Commandment #1 of the Software 
Engineers Ten Commandments (requirements for the other nine are still being 
collected :-)

I agree that "cvs add" does just what it should do, but I can understand 
the desire for a "cvs add-with-ignore" command.

It wouldn't be too hard to write a shell script "cvs-my-add" that trimmed 
the list of files on the command line based on the contents of ./.cvsignore 
and called "cvs add".

In order to get the build-in list and the $(CVSROOT)/CVSROOT/cvsignore 
list, you would have to do ugly things in a shell script, or build a new 
command into cvs. The current list of CVS maintainers does not seem to have 
the inclination to do this.

Hey, it's Open Source. If you want it bad enough, you can add it. If you 
make it a separate command (or possibly enabled with a special option to 
add), then there's a chance it might be accepted by the current maintainers 
for the next release. I think that there's some file named "Hacking" or 
something like that which has requirements for getting something into cvs.

Fred

___
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

web site management / security issues

[Menge, Oliver]

Hello,

I bekame webmaster of a small web site and want to introduce cvs as source
repository for html and the like. I used cvs successfully for software
projects and assume that it's well suited for a html-directory tree.
Somebody disagrees?

My second question is about client/server cvs, which is rather new to me.
The internet host where I would like to have the repository is a W2K
machine and I have to live with that. Cederquist says:

'anyone who gets the password gets repository access, and some measure of
 general system access as well.'

I have not much idea of Windows' security concept, so maybe somebody could
advise me, which access method is safe and does not require (too much of)
additional software.

Thanks in advance,

Oliver Menge

-- 
Oliver Menge
IT-Support JOE-List
(Junge Osteuropa Experten)
mailto:[EMAIL PROTECTED]
http://www.joe-list.de


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Is it possible to make CVS send email notification withchangesintroduced into committed file version

[Uri Abramov]

Thanks a lot for your responses guys.

Could you clarify How can I run "cvs diff" command from one of the scripts with I 
included into loginfo file. It seems to me that "cvs diff" command works only when it 
is executed from working directory. 
Is it right ?
If yes , Does anybody know any workaround ? 

Thanks.
Uri 

-Original Message-
From: Jenn Vesperman [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 05, 2003 10:56 AM
To: Uri Abramov
Cc: [EMAIL PROTECTED]
Subject: Re: Is it possible to make CVS send email notification
withchanges introduced into committed file version


On Thu, 2003-06-05 at 22:38, Uri Abramov wrote:
> Hi, 
> 
> I have two questions :
> 
> 1. Is it possible to add new administrative file under CVSROOT in such way that it 
> would be treated by cvs as it treads it's native administrative files. I mean always 
> keep in repository  file,v and file. If it' possible how can I do it ?

Yes. There's a file called .. I think it's called checkoutlist. One
moment...

... yes. Checkoutlist. Look for the node 'checkoutlist' in info cvs,
it's under 'administrative files'.

Simply add the filename (and maybe path from CVSROOT) in the
'checkoutlist' file in CVSROOT, and it will be treated as an
administrative file.


> 2. I'd like CVS send email to every developer who works on certain project when 
> someone from them remove, add or change file, and more than that I'd like to send in 
> the email the diff between old and new versions of a file. Does anybody knows how it 
> can be done?
> If yes How ?

You can use the cvs watch, or the 'loginfo' file, to do this during
commits. See the 'notify' administrative file and the 'watch' commands
in 'info cvs', or the 'loginfo' administrative file.

You would include 'cvs diff' as part of the command run from 'notify' or
'loginfo'. Pipe the results of the diff into an email, and send the
email. (Make sure you background the command, to prevent deadlocks.)




Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.
   My book 'Essential CVS': published by O'Reilly in June 2003.
[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: .cvsignore file being ignored

[Alexandre Augusto Drummond Barroso]

Sometimes we need to protect some users from themselves.
Usually I don't do what I'll describe here with regular IT 
users, but I have an exception: non technical users that 
creates docbook documents in the company I work for. 
The only thing they know is to click buttons in a specified 
order. 
If they do something different, they just don't know how to 
proceed (and usually don't even know witch button they 
pressed before something goes wrong). These days this kind 
of user is rare but they still exist. For this small group 
of users I use to create specific configurations and scripts 
(altering CVSROOT module's files like commitinfo, taginfo, 
and so) and I use to create macros to minimize user 
interface interactions and to avoid errors.

But I advise you to use this approach just for this almost 
extinct specie of end user.

Regards,

Xandao.

> -Original Message-
> From: Greg A. Woods [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 04, 2003 9:58 PM
> To: CVS-II Discussion Mailing List
> Subject: Re: .cvsignore file being ignored
> 
> 
> [ On Wednesday, June 4, 2003 at 16:34:23 (-0700), Peschko, 
> Edward wrote: ]
> > Subject: 
> >
> > It is in the sense that you are forcing people to do extra work.
> > Extra work == extra possibilities for error. 
> 
> You simply cannot ever stop users from causing themselves extra
> problems, no matter how much you might want to try.
> 
> You can only train them as best as possible and hope that the training
> sticks or eventually catches on.
> 
> > argh. people do "cvs add *" all the time.
> 
> I personally don't know of anyone who does "cvs add *" all of the time
> and without understanding that it will do exactly what they tell it to
> do.  (That's not to say that people who I know don't do this sometimes
> and without the outcome they expect -- but I've never observed anyone
> doing this after having done it once and learned that it's 
> not the right
> thing to do, just like "rm *" is rarely the right thing to do.)
> 
> If you do know such people then it is your duty to teach them to use
> their tools more properly!
> 
> > Why not change CVS and let them do this
> 
> Because it's FAR too late for such a fundamental change.  You 
> can't just
> arbitrarily invert the way the UI and a key feature like the 
> .cvsignore
> file works in a widely used tool, especially when that tool is used by
> other tools that you don't maintain!
> 
> Arguing various minor features, and discussing blue-sky ideas is one
> thing, but if you really want to see the fur fly you just go ahead and
> try actually making such an arbitrary change in tool like CVS and then
> try getting the masses to use your new version!  ;-)
> 
> 
> > if the administrator doesn't mind?
> 
> The "CVS administator"?  As in the manager of the CVS repository that
> the user is using?  What do they have to do with any of this 
> other than
> maybe being partly responsible for the ignorance of their users?
> 
> 
> > The 'trivially undone' part isn't the point.
> 
> Yes, it is the point, actually.
> 
> CVS does what you tell it to do.  If you change your mind then you can
> always undo what you've told it.  With "cvs add *" the undoing is even
> easier than with most other sub-commands because at that point nothing
> has yet modified the repository and no permanent change has 
> been made to
> anything.
> 
> You can't stop the user from running "cvs add foo.temporary", but the
> user can trivially run "cvs rm foo.temporary" without you ever knowing
> about it.  The effect of and the undoing of "cvs add *" is _literally_
> NO different, not one bit different.
> 
> If you really want to stop your users from doing stupid things with
> filename wildcards then you should force them to use a shell that
> doesn't support such "dangerous" features.  That is the only correct
> solution to your problem which doesn't involve someone having to
> actually LEARN something.  (Heaven forbid that anyone ever 
> have to learn
> anything about how their tools work!)
> 
> 
> > The point is that 
> > you are forcing people to go through extra hoops to get
> > stuff done,
> 
> Nobody's forcing anyone to use wildcards or even to use shells that
> implement wildcard filename matching.
> 
> The wildcard matching feature provided by many command-line 
> environments
> is one that helps people avoid having to go through extra hoops to get
> stuff done.  If people are instead abusing this feature and 
> thus causing
> themselves problems then the right solution isn't to force 
> everyone else
> in the world to change how they do things, but rather to 
> teach those few
> users who are having trouble to either make more appropriate 
> use of such
> powerful features as wildcards; or else to avoid using features which
> might not do what they want or what they intuitively believe.
> 
> The next thing I'm afraid you'll be saying is that "rm *" 
> should always
> warn the user that they're about to delete all their files.  Well, no,

Re: Is it possible to make CVS send email notification withchanges

[Larry Jones]

Uri Abramov writes [still in very long lines]:
> 
> Could you clarify How can I run "cvs diff" command from one of the
> scripts with I included into loginfo file. It seems to me that "cvs
> diff" command works only when it is executed from working directory. 

The loginfo script runs in the working directory (or a copy of it if
you're using client/server mode).

-Larry Jones

It's SUSIE!  It's a GIRL!  Santa would understand! -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: web site management / security issues

[Jenn Vesperman]

On Fri, 2003-06-06 at 02:38, Menge, Oliver wrote:

> My second question is about client/server cvs, which is rather new to me.
> The internet host where I would like to have the repository is a W2K
> machine and I have to live with that. Cederquist says:

> I have not much idea of Windows' security concept, so maybe somebody could
> advise me, which access method is safe and does not require (too much of)
> additional software.

ext with ssh is my favourite for a default setup. 

The server doesn't need any extra setup (though I'm not sure how CVS
works on Win 2K - I assume you'd be using CVSNT?), but does need an SSH
server installed.

The clients need an SSH client that's compatible with the SSH server
(make sure you use ssh2 on both, or ssh1 on both).

They also need the environment variable CVS_RSH set to the ssh program,
or if you're using a CVS client such as WinCVS, the appropriate setting
in the client set to the ssh program.

You may need to set up ssh keys on the client and server, and
appropriate logins. I've also found with putty (on Windows clients), I
need to run pageant in the background.


After that, it should all 'just work'.


Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.
   My book 'Essential CVS': published by O'Reilly in June 2003.
[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Jenn Vesperman]

On Fri, 2003-06-06 at 01:02, Frederic Brehm wrote:
> At 10:08 AM 6/5/2003, Larry Jones wrote:
> >There's nothing I hate more than software that thinks it
> >knows more than I do and refuses to let me do what I want to do.
> 
> The principal of least surprises should be Commandment #1 of the Software 
> Engineers Ten Commandments (requirements for the other nine are still being 
> collected :-)

> I agree that "cvs add" does just what it should do, but I can understand 
> the desire for a "cvs add-with-ignore" command.

> Hey, it's Open Source. If you want it bad enough, you can add it. If you 
> make it a separate command (or possibly enabled with a special option to 
> add), then there's a chance it might be accepted by the current maintainers 
> for the next release. I think that there's some file named "Hacking" or 
> something like that which has requirements for getting something into cvs.

Agreed. cvs add -i, or some such. 

Then you can put it in your .cvsrc as a default, so that you always get
the behaviour you want, and the rest of us get the behaviour we expect.



Jenn V.
-- 
"Do you ever wonder if there's a whole section of geek culture 
you miss out on by being a geek?" - Dancer.
   My book 'Essential CVS': published by O'Reilly in June 2003.
[EMAIL PROTECTED] http://anthill.echidna.id.au/~jenn/




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Is it possible to make CVS send email notification withchanges introduced into committed file version

[Miller Dale Contractor HQ AFWA]

Uri Abramov writes:
> Could you clarify How can I run "cvs diff" command from one 
> of the scripts with I included into loginfo file. It seems to 
> me that "cvs diff" command works only when it is executed 
> from working directory. 
> Is it right ?
> If yes , Does anybody know any workaround ? 
> 

cvs rdiff does not require a working directory, however, by default it gives
you a context diff.

Dale Miller


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Larry Jones]

Peschko, Edward writes:
> 
> Why the resistance to what would be a trivial feature?

Because even trivial features are expensive.  They clutter up the code,
the test suite, the documentation, and the users' minds.  In this case,
it encourages a bad, some would even say dangerous, habbit (expecting
software to second guess you and do what you want instead of what you
told it to do).

-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: .cvsignore file being ignored

[Greg A. Woods]

[ On Thursday, June 5, 2003 at 15:45:52 (-0300), Alexandre Augusto Drummond Barroso 
wrote: ]
> Subject: RE: .cvsignore file being ignored
>
> Sometimes we need to protect some users from themselves.
> Usually I don't do what I'll describe here with regular IT 
> users, but I have an exception: non technical users that 
> creates docbook documents in the company I work for. 
> The only thing they know is to click buttons in a specified 
> order. 

Yes, exactly.

Non-technical users should be given a (G)UI that's more intuitive for
the kind of work they do, _or_ they should be trained suitably so that
they will no longer be classified as "non-technical users".

Note that I am what I think most people would call an experienct
"technical" user, however most of the time I use PCL-CVS as a front-end
to CVS.  I only use the command line when I have unique requirements
that are not easy/possible to do with PCL-CVS.

I.e. even technical users can sometimes make better use of their tools
when they are given an integrated environment.

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Peschko, Edward]

>> If we don't want .exe files in the repository, the add command should defend that 
>> decision for us, even if weakly.

> I happen to disagree strongly . . . There's nothing I hate more than software that 
> knows
> more than I do.. etc. etc. etc

But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) 
is to be able 
to *customize* the software to be able to exclude files. You don't need to use it! If 
you've got
directories where you know what you are doing, put a blank .cvsblock file in it!

Why the resistance to what would be a trivial feature?

Ed


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Input read error: editor session failed

[Calvin Smith]

I am getting an error that I have seen other posts about but not been able
to find a solution to.  When I try to commit a file, I get the following
error:

Input read error
cvs server: warning: editor session failed

Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining
dirs
cvs server: cannot read from stdin: No such file or directory
cvs [server aborted]: aborting
Action: (continue)

I am using cvs 1.11.2 on Linux (client) and Solaris (server). I get this
error when I use vi, vim, gvim, or nano as the editor. Anybody
figure a way to use some version of vi as the editor for cvs. I gather
that this has something to do with the return value of the editor.

thanks,

calvin









___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

correct protocol to list a directory?

[Danny Sauer]

I'm trying to write a pserver client in perl that'll generate a directory
listing from a CVS pserver (though, I suppose pserver has little to do
with it at that point in the communication chain).  There's actually a
larger goal here, but the dir listing is my main remaining problem. 
Here's what I've got ($cvs is an IO::Socket::INET object, and "print" is
just what I'm using for debugging output right now):

print $cvs 'Root /cvs/danny', "\n";
print $cvs 'Valid-responses ok error E M Valid-requests Checked-in Merged
Removed Updated', "\n";
print $cvs 'Argument -R', "\n";
print $cvs 'Directory .', "\n";
print $cvs '/cvs/danny/perl', "\n";
print $cvs 'Argument teleo', "\n";
print $cvs 'log', "\n";
while(<$cvs>){
print;
last if /^(?:ok|error)\s*/;
}

The CVS root is /cvs/danny, the module is "perl", and there's a "teleo"
directory in that module.  For example. :)  I've tried a few combinations
of those commands in a few different orders, and without the "Directory"
line.  I'm clearly just missing *something* here.  I can get a directory
listing by checking out the dir, but that transferes all of the files
(recursively), which is a big ol' waste of bandwidth and CPU.  The list
archives menstion using the "rlog" command, which has apperently been
deprecated in favor of "log" - and rlog doesn't work any better for me
anyway.  The example above is based on seeing what the command-line client
does with a packet sniffer, and the docs (cvsclient.texi) just aren't
quite giving me what I need to know. :)

Thanks in advance.
--Danny


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Greg A. Woods]

[ On Thursday, June 5, 2003 at 11:42:37 (-0700), Peschko, Edward wrote: ]
> Subject: Re: .cvsignore file being ignored
>
> But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) 
> is to be able 
> to *customize* the software to be able to exclude files.

What you don't understand is that this decision was made a long time
ago. 

CVS already provides a way to *customize* the software to be able to
exclude files.  It's called the "ignore" list and it is customized with
the .cvsignore file and the '-I' command-line option.  However this
particular choice of implementation requires that there be a way to
explicitly track changes to specified files that would otherwise be
ignored, and that is done with the "cvs add" command.  If you want CVS
to continue to ignore some of your files then don't add them!  RTFM!

> You don't need to use it!

You can not have it both ways.  I.e. you cannot have an "ignore" list
that blocks and a "block" list that ignores.  The decision about how CVS
works was made when the "ignore" list was chosen and now that's the way
CVS works.  Like it or lump it.

If you really want it the other way around, and embedded directly in the
main program instead of in some wrapper or front-end, then I humbly
suggest you fork CVS, call your version "SVC" or something, and do it
your way.  CVS is "free" software, as in "free speech".

> Why the resistance to what would be a trivial feature?

It's not a "trivial feature" -- it is a complete and utter reversal of
the current mechanism of handling file lists for "cvs add".

If you don't understand that then you must really not understand the
full implications of wildcard filename expansion at the shell level.

Why don't you try approaching your shell vendor and ask them to
implement your feature for you at the shell level where you seem to want
it to be?  That way CVS will never see any filenames that you don't want
it to see.  Good luck.

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Is it possible to make CVS send email notification withchangesintroduced into committed file version

[Mark D. Baushke]

Uri Abramov <[EMAIL PROTECTED]> writes:

> Thanks a lot for your responses guys.
> 
> Could you clarify How can I run "cvs diff" command from one of the
> scripts with I included into loginfo file. It seems to me that "cvs
> diff" command works only when it is executed from working directory.
> Is it right ? If yes , Does anybody know any workaround ?

If you run the diff from the commitinfo or loginfo specified script,
then the current working directory contains the files of interest along
with a reasonable CVS/Entries file. However, you will want to avoid
creating any cvs locks. So, a reasonable cvs diff command might be

 cvs -f -Q -n diff -up

If you are using :pserver: then you may not need the -f option to
disable reading a ~/.cvsrc file for the user. You may or may not want
the -Q option, but you really do need the -n option.

You may or may not want to worry about binary files and the like...

Good luck,
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Kaz Kylheku]

On Thu, 5 Jun 2003, Peschko, Edward wrote:

> >> If we don't want .exe files in the repository, the add command should defend that 
> >> decision for us, even if weakly.
> 
> > I happen to disagree strongly . . . There's nothing I hate more than software that 
> > knows
> > more than I do.. etc. etc. etc
> 
> But that's what I don't understand. The idea behind .cvsblock (or TYPES or whatever) 
> is to be able 

I think that .cvsblock is silly; the tiny semantics difference between
that and .cvsignore is not worth it. The cvs add command should ignore
things that match .cvsignore, period. Those who disagree: what part of
``cvs'' and ``ignore'' isn't clear?

An interactive error would be a reasonable compromise. The software
notices that the user requested to add files which match the .cvsignore
specification, and so brings up a menu: add this file anyway, skip it,
apply this action to all the rest.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: info-cvs@gnu.org

[Peschko, Edward]

> Because even trivial features are expensive...

sheesh. you've got all the hooks there to do it, the logic
there to do it, it would probably be 5 lines of code, and
about 4 lines of documentation. That's expensive? Its the
philosophical part you don't like, and you really should
let the user decide on whether they want software that DWIM.

Anyways, I agree with you Kaz... That's how I was *using*
.cvsignore - thinking that was giving me some sort of protection
against certain files being checked in. Until I looked at the
code, and saw it was doing no such thing - and proceeded to
look at the cvs trees that I'd set up (but no longer actively
maintain) and found out they were cluttered with junk. 

.cvsblock was just a sap for backwards compatibility.
I like your sap for backwards compatibility better.

Ed


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: correct protocol to list a directory?

[Larry Jones]

Danny Sauer writes:
> 
> The list
> archives menstion using the "rlog" command, which has apperently been
> deprecated in favor of "log" - and rlog doesn't work any better for me
> anyway.

What release of CVS are you running?  rlog *used* to be a deprecated
synonym for the log command, now it's a separate variant that doesn't
need a working directory.

> The example above is based on seeing what the command-line client
> does with a packet sniffer, and the docs (cvsclient.texi) just aren't
> quite giving me what I need to know. :)

No need to use a packet sniffer, just set $CVS_CLIENT_LOG and peruse the
resulting log files at your leisure.

-Larry Jones

I'm getting disillusioned with these New Years. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Input read error: editor session failed

[Larry Jones]

Calvin Smith writes:
> 
> Input read error
> cvs server: warning: editor session failed

The CVS server is trying to run the editor rather than the client.  That
doesn't work because the server isn't connected to any terminal.  There
was a bug that was fixed a release or two ago that would cause that to
happen if you specified an empty log message (e.g., cvs ci -m''), but it
shouldn't ever happen otherwise.

-Larry Jones

Your bangs do a good job of covering up the lobotomy stitches. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: correct protocol to list a directory?

[Alexander Taler]

You might want to consider the libcvs project.  We already have a
mostly workable library in Perl, which should see its first
release sometime soon.  http://libcvs.cvshome.org/

Alex

> "Danny" == Danny Sauer <[EMAIL PROTECTED]> writes:
  Danny> To: [EMAIL PROTECTED]
  Danny> Subject: correct protocol to list a directory?
  Danny> Date: Thu, 5 Jun 2003 15:57:38 -0500 (CDT)

  Danny> I'm trying to write a pserver client in perl that'll generate a
  Danny> directory listing from a CVS pserver (though, I suppose pserver has
  Danny> little to do with it at that point in the communication chain).
  Danny> There's actually a larger goal here, but the dir listing is my main
  Danny> remaining problem.  Here's what I've got ($cvs is an IO::Socket::INET
  Danny> object, and "print" is just what I'm using for debugging output right
  Danny> now):

  Danny> print $cvs 'Root /cvs/danny', "\n"; print $cvs 'Valid-responses ok
  Danny> error E M Valid-requests Checked-in Merged Removed Updated', "\n";
  Danny> print $cvs 'Argument -R', "\n"; print $cvs 'Directory .', "\n"; print
  Danny> $cvs '/cvs/danny/perl', "\n"; print $cvs 'Argument teleo', "\n"; print
  Danny> $cvs 'log', "\n"; while(<$cvs>){
  Danny> print; last if /^(?:ok|error)\s*/;
  Danny> }

  Danny> The CVS root is /cvs/danny, the module is "perl", and there's a
  Danny> "teleo" directory in that module.  For example. :) I've tried a few
  Danny> combinations of those commands in a few different orders, and without
  Danny> the "Directory" line.  I'm clearly just missing *something* here.  I
  Danny> can get a directory listing by checking out the dir, but that
  Danny> transferes all of the files (recursively), which is a big ol' waste of
  Danny> bandwidth and CPU.  The list archives menstion using the "rlog"
  Danny> command, which has apperently been deprecated in favor of "log" - and
  Danny> rlog doesn't work any better for me anyway.  The example above is
  Danny> based on seeing what the command-line client does with a packet
  Danny> sniffer, and the docs (cvsclient.texi) just aren't quite giving me
  Danny> what I need to know. :)

  Danny> Thanks in advance.  --Danny



-- 
http://libcvs.cvshome.org/Access CVS through a library. 
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
"Fido Bakin is my name."
   -- The Two Towers, Malaysian edition


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Greg A. Woods]

[ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ]
> Subject: Re: .cvsignore file being ignored
>
> I think that .cvsblock is silly; the tiny semantics difference between
> that and .cvsignore is not worth it. The cvs add command should ignore
> things that match .cvsignore, period.

Because it was decided long ago that "cvs add" would be how all files
would be tagged for adding to the repository, including those that would
otherwise be ignored by default.

> Those who disagree: what part of
> ``cvs'' and ``ignore'' isn't clear?

What part of "Do What I Say!" don't you understand?  CVS just does
exactly, and only, what you're telling it to do when you give it a file
or a list of files on the command line.  Why should users have to jump
through extra hoops just to cause CVS to do what they're trying to tell
it to do in the first place?

If you don't want to add a file then do not include its name on the "cvs
add" command line!

This basic UI decision is part of history now.  Like it or lump it.

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PROTECTED]>;   <[EMAIL PROTECTED]>
Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]>


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Input read error: editor session failed

[Calvin Smith]

On Thu, 5 Jun 2003, Larry Jones wrote:

> Calvin Smith writes:
> >
> > Input read error
> > cvs server: warning: editor session failed
>
> The CVS server is trying to run the editor rather than the client.  That
> doesn't work because the server isn't connected to any terminal.  There
> was a bug that was fixed a release or two ago that would cause that to
> happen if you specified an empty log message (e.g., cvs ci -m''), but it
> shouldn't ever happen otherwise.

Thanks. I upgraded to the latest cvs and I don't have the problem anymore.

-calvin



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Thursday, June 5, 2003 at 14:00:12 (-0700), Kaz Kylheku wrote: ]
>> Subject: Re: .cvsignore file being ignored
>>
>> I think that .cvsblock is silly; the tiny semantics difference between
>> that and .cvsignore is not worth it. The cvs add command should ignore
>> things that match .cvsignore, period.

>Because it was decided long ago that "cvs add" would be how all files
>would be tagged for adding to the repository, including those that would
>otherwise be ignored by default.

I agree with the first part, but I don't believe that the second part
was really considered by the designer and the implementation came out
the way it did by default.

Consider the use of "cvs import", which obeys the .cvsignore file.  From
and end-user perspective, it's not unreasonable to expect the following:

- CVS behaves the same way with regard to processing the .cvsignore file
  during both add and import.
- CVS gives warnings or errors when a file named on the command line is
  omitted due to the .cvsignore file.  Ideally, it would issue errors
  and leave the Entries file alone.
- The "cvs add" command provides an option to ignore the contents of the
  .cvsignore file, just as "cvs import" does.

>> Those who disagree: what part of
>> ``cvs'' and ``ignore'' isn't clear?

>What part of "Do What I Say!" don't you understand?  CVS just does
>exactly, and only, what you're telling it to do when you give it a file
>or a list of files on the command line.  Why should users have to jump
>through extra hoops just to cause CVS to do what they're trying to tell
>it to do in the first place?

Why should users jump through hoops just to have CVS not do something they
don't expect?  If users are told that CVS is configured to ignore .o, .a,
and whatever types of files, then CVS should do just that.  It should not
just sometimes ignore them.

>If you don't want to add a file then do not include its name on the "cvs
>add" command line!

Not a valid argument when wildcards or xargs are in use.

>This basic UI decision is part of history now.  Like it or lump it.

The fact that a feature is implemented in a certain way does not make it
immutable.  It can, and should, be changed if ease of use is increased,
provided no utility is lost.  Justifying a broken UI because "that's just
the way it works" is nonsense.

>--- End of forwarded message from [EMAIL PROTECTED]



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Greg A. Woods]

[ On Thursday, June 5, 2003 at 15:23:16 (-0700), Paul Sander wrote: ]
> Subject: Re: .cvsignore file being ignored
>
> I agree with the first part, but I don't believe that the second part
> was really considered by the designer and the implementation came out
> the way it did by default.

Actually it was.  Search your list archives.

Usually every time it's been discussed since people are much quicker to
understand what Larry and I have been trying to say.  Perhaps that's
because previously more of those questioning this behaviour have had a
deeper understanding of what wildcard filename expansion really imply to
how command line interfaces work and how they must be used.

Once upon a time I posted:

CVS' "add" command, when used on a new file, tells the local
working directory that the new file is "source".  The CVS ignore
list can declare that a file is not source, *BUT* CVS is allowed
to over-ride the ignore list.  A "known" file will never be
ignored no matter how many times or places you put it into the
ignore list.

I.e. "cvs add" and .cvsignore compliment each other.

In other words the ignore list is _NOT_ used to control which files CVS
acts upon.  CVS always acts upon the files you tell it to act upon.

The ignore list is used only to control which files _not_ warned about
when CVS is operating in its normal recursive mode, since otherwise CVS
would warn the user to take control of all the files it finds in the
workspace.  The purpose of the ignore list is quite explictly _NOT_ to
prevent the user from telling CVS to treat a file as source which it
would otherwise ignore but rather it is there only to prevent CVS from
being too noisy about files it isn't already tracking in the repository.

> Consider the use of "cvs import", which obeys the .cvsignore file.

That's a historical artifact as well, though perhaps one that might be
easier to change than with "cvs add".

If I'm not mistaken the ignore list feature was originally designed only
to be used during "cvs update".  Conceptually its purpose is to deal
with working directories whenever CVS is doing its own directory
traversal.

I'm not sure when exactly "cvs import" first honoured the ignore list,
though with hindsight we can see that it should never have done so.
Unfortunately things only got worse when .cvsignore files were honoured
even when '-I !' is explicitly specified.  See the manual for further
discussion of this.

If you recall my proposal to enhance "cvs add" you might remember that I
suggested the new version would behave (with respect to directory names
given as command line parameters) as follows, simulating "cvs import" to
some extent, but at least fixing the documented bug in "cvs import -I !":

  - "cvs add dirname" will recurse through the specified directory
adding all new ``un-ignored'' files if the current directory, or one
of the parent directories, is a valid CVS working directory (as
above).  (including if "dirname" == "." || == "")

  - Nothing will be done if no new files are found to add.

  - "cvs add dirname" will honour the '-l', '-R', and '-I' "Common
Options" just as every other command which operates recursively.

  - "cvs add -I ! dirname" will not ignore any files, not even those
listed in any .cvsignore files, except of course all CVS
administrative sub-directories and their contents.

  - If "CVS" (admin subdir's name) is specified explicitly it will be
(silently unless -) ignored.

  - Variations of "newfile", "path/to/newfile", and "dirname" will be
accepted simultaneously on the command-line (just as with other CVS
commands).

  - no explicitly named file or directory will ever be ignored, even if
it would be ignored by the current "cvsignore" list (i.e. "-I !" is
not necessary for explicitly specified names that would be otherwise
ignored if they were simply implied by recursion)

I was reluctant to write the proposal this way and gave in only for the
case where the command line parameter is a directory name and thus would
trigger recursive operation.

We should have been happy with running "make distclean" before running
"cvs import".


> Why should users jump through hoops just to have CVS not do something they
> don't expect?

Because you can't have it both ways

The decision was made long ago and it has been happily accepted for many
years now.

> Not a valid argument when wildcards or xargs are in use.

Paul, please go back to basic unix school.  I.e. learn to use your tools
properly instead of abusing them!  Meanwhile here's how you should
remove all the object files in your source tree:

find . -print | xargs rm

Please try it out and let me know how it works.

If you don't understand how and why wildcards work then don't use them!

-- 
Greg A. Woods

+1 416 218-0098;<[EMAIL PRO

Re: .cvsignore file being ignored

[Mark D. Baushke]

Paul Sander <[EMAIL PROTECTED]> writes:

> Consider the use of "cvs import", which obeys the .cvsignore file.  

Yes, that 'cvs import' obeys the .cvsignore file is somewhat broken.
The '-I !' command-line option should be honored and should NOT process
either local .cvsignore files or the global CVSROOT/cvsignore file), but
it too late to fix it now...

The big thing to remember that is different between cvs import and cvs add
is that an import happens immediately while an add does not happen until
the 'cvs commit' occurs and any time up until the 'cvs commit' you may
remove files from the list of those that should not be committed.

In an different world perhaps only the new directories would be added to
the repository on a 'cvs import' and the import tree would become a
sandbox with all of the files having been 'added' to the repository, but
not yet committed. That different world might allow folks to make sure
that their master repository still worked properly with all of the new
imported files... Ah well, that is not this world today.

The way that 'cvs import' works was made long ago and a change to it
will not likely happen even though there is some merit in the fact that
a cvs import may appear to do the 'wrong' thing when some files have
local changes and others are unchanged after a cvs import occurs that
makes some of those new files visible, but not all of them. (I am still
pondering the order of an import versus work on a branch problem raised
in a different thread.)

In general, best practice would have you add a local change to all of
the imported files so that nothing on your HEAD would change when you
did the import until after you had merged all of the changes forward to
the HEAD... not everyone likes that methodology, so that is probably not
what folks do today...

> From and end-user perspective, it's not unreasonable to expect the
> following:
> 
> - CVS behaves the same way with regard to processing the .cvsignore file
>   during both add and import.

In theory, a user can type 'cvs import -I !' and have *all* of the files
imported... well, as long as they remove all of their .cvsignore files
first and emasculate any CVSROOT/cvsignore files. How do you proposed that
'cvs add' users get ALL of they files they explicitly request be added to
the repository added? Mind reading software is notoriously slow to get
into production for some reason.

> - CVS gives warnings or errors when a file named on the command line is
>   omitted due to the .cvsignore file.  Ideally, it would issue errors
>   and leave the Entries file alone.

I find this idea of an interface to be ugly...

> - The "cvs add" command provides an option to ignore the contents of the
>   .cvsignore file, just as "cvs import" does.
 
> Why should users jump through hoops just to have CVS not do something they
> don't expect?  If users are told that CVS is configured to ignore .o, .a,
> and whatever types of files, then CVS should do just that.  It should not
> just sometimes ignore them.

This sounds like an education problem to me. If you tell them that
whatever they put on the 'cvs add' command line will be added to the
repository, and that is what the command does, won't they expect that
behavior?

CVS is NOT configured to ignore .o .a and whatever types of files. It is
configured to suppress complaining about them when they are found in a
controlled directory.

> >--- Forwarded mail from Greg Woods:
> >If you don't want to add a file then do not include its name on the "cvs
> >add" command line!
> 
> Not a valid argument when wildcards or xargs are in use.

But the point is that any argument to cvs add is valid. That is what we
have been saying all along...

If I need/want to do

   cvs add lib-a-purchased-library.a

to add a .a file obtained from a third party to my sources, why should
cvs ignore that I have done this? The cvs command is not able to
distinguish this from the

   cvs add *.a

command in a directory which contains only the single
lib-a-purchased-library.a file.

> >This basic UI decision is part of history now.  Like it or lump it.
> 
> The fact that a feature is implemented in a certain way does not make it
> immutable.

Certainly, the software is not immutable. 

You yourself have the sources and therefore the ability to do anything
you wish to them. I have no problems with you choosing to do anything
you wish to your copy of the sources and I encourage you to make the
changes you believe will improve the product and deploy them into your
environment for testing and production. Feel free to update your sources
as often as you wish out of the cvshome.org repository or periodic
source distributions.

If your patch is particularly elegant and desirable, who knows, someone
may add it to the repository for you.

However, you may find your time is better used if you go and use
Meta-CVS instead of vanilla CVS. It appears to already have the feature
you desire and Kaz Kylheku has been very responsive to prob

Help: Linux CVS Server Access Problem

[Hill, Benjamin W]

I am setting up a CVS repository on a Redhat 9 Linux server in a directory
"/cvs/repository", but am having some problems.

I have set up the repository, and on the box itself can do a:

bash# export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/repository
bash# cvs login

And I can authenticate, and then check out code in the repository fine. The
problem is when I try to connect to the server remotely and do the same
thing.

I have:

* disabled the firewall using "redhat-config-securitylevel"

* Added the file; /etc/xinetd.d/cvspserver with the contents:

service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server  = /usr/bin/cvs
server_args = --allow-root=/cvs/repository pserver -f
}

(and restarted xinet.d)

* checked via a netstat that there is a LISTEN for cvspserver.

The server is using DHCP to obtain an IP.

Anything else I can try?

Cheers,

Ben

---

Software Engineer [SCJP] Specialist, SME Java Technologies
Member Institute of Software Architects [www.wwisa.org]

EDS EMEA Solutions Consulting - UK North East & Scotland
mail: [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Help: Linux CVS Server Access Problem

[Gurpreet Singh (SCM)]

Specific error ... 

Still may Check with the following file
1. /etc/inetd.conf  for :
cvspserver stream tcp   nowait  root/usr/sbin/tcpd  /usr/bin/cvs -f
--allow-root=/CVS/repository pserver

2. /etc/servicesfor:
cvspserver  2401/tcp# cvspserver
cvspserver  2401/udp# cvspserver

3. Try giving the server IP rather the server name - directly !^!



Gurpreet S


-Original Message-
From: Hill, Benjamin W [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 4:46 PM
To: '[EMAIL PROTECTED]'
Subject: Help: Linux CVS Server Access Problem


I am setting up a CVS repository on a Redhat 9 Linux server in a directory
"/cvs/repository", but am having some problems.

I have set up the repository, and on the box itself can do a:

bash# export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/repository
bash# cvs login

And I can authenticate, and then check out code in the repository fine. The
problem is when I try to connect to the server remotely and do the same
thing.

I have:

* disabled the firewall using "redhat-config-securitylevel"

* Added the file; /etc/xinetd.d/cvspserver with the contents:

service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server  = /usr/bin/cvs
server_args = --allow-root=/cvs/repository pserver -f
}

(and restarted xinet.d)

* checked via a netstat that there is a LISTEN for cvspserver.

The server is using DHCP to obtain an IP.

Anything else I can try?

Cheers,

Ben

---

Software Engineer [SCJP] Specialist, SME Java Technologies
Member Institute of Software Architects [www.wwisa.org]

EDS EMEA Solutions Consulting - UK North East & Scotland
mail: [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Deleting a branch....

[Gurpreet Singh (SCM)]

Hi All

This is regarding deleting a branch, thus created on a Module.
Is there any specific method / decription in doing it so ?

Well I tried to untag it  ^ with the following command 

cvs rtag -d BranchName ModuleName
Is this the only way to do so..?

Moreover, All the subfolders were not untagged / say deletion of branch
completely... ?

Thanks in advance ^^  
 
Gurpreet S 



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Help: Linux CVS Server Access Problem

[Hill, Benjamin W]

I only have xinetd as it is RH9, but I have the /etc/services entry in
there. 

I have tried the IP also, and no luck :-(

Cheers,

Ben

-Original Message-
From: Gurpreet Singh (SCM) [mailto:[EMAIL PROTECTED] 
Sent: 06 June 2003 13:03
To: Hill, Benjamin W
Cc: '[EMAIL PROTECTED]'
Subject: RE: Help: Linux CVS Server Access Problem


Specific error ... 

Still may Check with the following file
1. /etc/inetd.conf  for :
cvspserver stream tcp   nowait  root/usr/sbin/tcpd  /usr/bin/cvs -f
--allow-root=/CVS/repository pserver

2. /etc/servicesfor:
cvspserver  2401/tcp# cvspserver
cvspserver  2401/udp# cvspserver

3. Try giving the server IP rather the server name - directly !^!



Gurpreet S


-Original Message-
From: Hill, Benjamin W [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 4:46 PM
To: '[EMAIL PROTECTED]'
Subject: Help: Linux CVS Server Access Problem


I am setting up a CVS repository on a Redhat 9 Linux server in a directory
"/cvs/repository", but am having some problems.

I have set up the repository, and on the box itself can do a:

bash# export CVSROOT=:pserver:[EMAIL PROTECTED]:/cvs/repository
bash# cvs login

And I can authenticate, and then check out code in the repository fine. The
problem is when I try to connect to the server remotely and do the same
thing.

I have:

* disabled the firewall using "redhat-config-securitylevel"

* Added the file; /etc/xinetd.d/cvspserver with the contents:

service cvspserver
{
socket_type = stream
protocol= tcp
wait= no
user= root
passenv =
server  = /usr/bin/cvs
server_args = --allow-root=/cvs/repository pserver -f
}

(and restarted xinet.d)

* checked via a netstat that there is a LISTEN for cvspserver.

The server is using DHCP to obtain an IP.

Anything else I can try?

Cheers,

Ben

---

Software Engineer [SCJP] Specialist, SME Java Technologies Member Institute
of Software Architects [www.wwisa.org]

EDS EMEA Solutions Consulting - UK North East & Scotland
mail: [EMAIL PROTECTED]


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: WinCvs1.2 - Problem

[Larry Jones]

Jayashree writes:
> 
> I am facing a peculiar problem with check in/out in CVS. I 
>  am using Wincvs 1.2 version. I checked out a 
> document of size 5kb. Updated some sections and 
> checked in. ( forced binary format). ( Size is 7 KB now).

I'm not entirely sure what you mean by "forced binary format".  If the
repository file isn't marked as binary (you can use "cvs log -h" to
check), you're going to have problems.  You can use "cvs admin" to fix
it, if that's the problem.

-Larry Jones

The hardest part for us avant-garde post-modern artists is
deciding whether or not to embrace commercialism.  -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: A series of CVS questions.

[Larry Jones]

Sam Talebbeik writes:
> 
> I have a long list of feature questions about CVS. I have used CVS on a
> previous project years back. I am currently using a "commercial" product 
> in my present project. I would like to know if certain features of 
> this "commercial" product are or will be available in CVS.
> 
> Is this the right forum to ask these questions ? 

Yes, and no.  This is the right place to ask *after* you've made an
attempt to get your own answers by consulting .

-Larry Jones

Hmph. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Help: Linux CVS Server Access Problem

[Larry Jones]

"Gurpreet Singh (SCM)" writes:
> 
> 2. /etc/servicesfor:
> cvspserver  2401/tcp# cvspserver
> cvspserver  2401/udp# cvspserver

CVS has never used UDP (and almost certainly never will), so there's no
reason to have the second line.

-Larry Jones

These child psychology books we bought were such a waste of money.
-- Calvin's Mom


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: .cvsignore file being ignored

[Larry Jones]

Mark D. Baushke writes:
> 
> The big thing to remember that is different between cvs import and cvs add
> is that an import happens immediately while an add does not happen until
> the 'cvs commit' occurs and any time up until the 'cvs commit' you may
> remove files from the list of those that should not be committed.

No, the big thing to remember that is different between import and add
is that add takes an explicit list of files to process whereas import
does not.  .cvsignore *never* overrides an explicit file specification
by the user (nor should it), it only affects what files CVS processes
when it's generating the list of files itself.

-Larry Jones

My upbringing is filled with inconsistent messages. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Help: Linux CVS Server Access Problem

[Hill, Benjamin W]

Hi,

I have been through the troubleshooter, but not found anything I haven't
tried.

When I try to connect to the server from a Windows machine using:

set cvsroot=:pserver:[EMAIL PROTECTED]:/cvs/repository
cvs login [USERNAME]

..I get the line:

"CVS password:"

...but when I enter a password I get:

"cvs [login aborted]: connect to [SERVERNAME]([SERVERNAME]):2401 failed: No
connection could be made because the target machine actively refused it."

I have checked that the cvspserver file is in /etc/xinetd.d and that there
is a LISTEN entry when doing a netstat.

I can however log in from the Linux box itself using:

export cvsroot=:pserver:[EMAIL PROTECTED]:/cvs/repository
cvs login [USERNAME]

..and check out code etc. I will look at the pserver -f bit though!

Cheers,

Ben

-Original Message-
From: Jones, Larry 
Sent: 06 June 2003 16:17
To: Hill, Benjamin W
Cc: [EMAIL PROTECTED]
Subject: Re: Help: Linux CVS Server Access Problem


Hill, Benjamin W writes:
> 
> And I can authenticate, and then check out code in the repository 
> fine. The problem is when I try to connect to the server remotely and 
> do the same thing.

See the troubleshooting advice in the manual:



If that doesn't help, feel free to ask for help, but at least tell us
exactly what the problem is!

> server_args = --allow-root=/cvs/repository pserver -f

The -f belongs before pserver, not after.

-Larry Jones

Oh, what the heck.  I'll do it. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Help: Linux CVS Server Access Problem

[Larry Jones]

Hill, Benjamin W writes:
> 
> And I can authenticate, and then check out code in the repository fine. The
> problem is when I try to connect to the server remotely and do the same
> thing.

See the troubleshooting advice in the manual:



If that doesn't help, feel free to ask for help, but at least tell us
exactly what the problem is!

> server_args = --allow-root=/cvs/repository pserver -f

The -f belongs before pserver, not after.

-Larry Jones

Oh, what the heck.  I'll do it. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Help: Linux CVS Server Access Problem

[Larry Jones]

Hill, Benjamin W writes:
>
> MIME-Version: 1.0
> Content-Type: multipart/mixed;

Please do not post MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!

> cvs login [USERNAME]

login does not take any parameters (it gets everything from CVSROOT).

> "cvs [login aborted]: connect to [SERVERNAME]([SERVERNAME]):2401 failed: =
> No connection could be made because the target machine actively refused =
> it."

This implies that nothing is listening at port 2401 on the server. 
Since you say it works on the server itself, I can only conclude that
you're not connecting to the machine you think you are.  Or you have an
unusual firewall of some sort that is preventing the connection (normal
firewalls either result in a timeout or a successful connection that is
immediately closed).

-Larry Jones

>From now on, I'm devoting myself to the cultivation of
interpersonal relationships. -- Calvin


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: Deleting a branch....

[Max Bowsher]

Gurpreet Singh (SCM) wrote:
> Hi All
>
> This is regarding deleting a branch, thus created on a Module.
> Is there any specific method / decription in doing it so ?
>
> Well I tried to untag it  ^ with the following command
>
> cvs rtag -d BranchName ModuleName
> Is this the only way to do so..?
>
> Moreover, All the subfolders were not untagged / say deletion of branch
> completely... ?

Deleting a branch is not usually a good idea.

Simply untagging (rtag -d) saves virtually no space in the repository,
because all the revisions remain there, but they are now anonymous and
inaccessible except by revision number on an individual file basis.

So, basically, don't delete branches.


Max.



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

sspi

[Mac]

Hello there,
Does anyone know how to switch from pserver to sspi when connecting to cvs? 
In other words, how to set the cvs using sspi?
Thank you much.
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

set 1 file in repository to be read only

[Tumy, Brad]

This question is more for a sanity check then anything else.

If I want one specific file in the repository to be read-only (to all
developers) then I just set the permissions on that file (through OS
[Solaris]) to be read-only ...correct? 

We are developing a web-application in Cold Fusion and I want to lock down
the top Application.cfm file so that developers can check it out and include
it in their working directory but not be able to commit it back to the
repository.

Thanks,
Brad


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

How connect to CVS sever via ssh

[Uri Abramov]

Hello to everybody,


I tried to configure WinCVS to connect to CVS server via ssh , I generated private and 
public RSA keys, moved private key to local host and etc.
But when I try execute any operation on WinCVS it demand to enter password, whereas I 
connect to my server from dos by executing
"ssh -1 [EMAIL PROTECTED]"  command I get connected without entering password.

Does anybody know how to configure WinCVS in a such way that it won't demand to enter 
password for every operation ?

Thanks in advice.
Uri 


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: sspi

[Mark D. Baushke]

Mac <[EMAIL PROTECTED]> writes:

> Hello there,
> Does anyone know how to switch from pserver to sspi when connecting to cvs? 
> In other words, how to set the cvs using sspi?

The cvshome.org version of CVS does not support the :sspi: method. You
will need to look into using http://www.cvsnt.org which does support
both :sserver: and encrypted :sspi: methods.

Good luck,
-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: set 1 file in repository to be read only

[Mark D. Baushke]

Tumy, Brad <[EMAIL PROTECTED]> writes:

> This question is more for a sanity check then anything else.
> 
> If I want one specific file in the repository to be read-only (to all
> developers) then I just set the permissions on that file (through OS
> [Solaris]) to be read-only ...correct? 

No.
 
> We are developing a web-application in Cold Fusion and I want to lock down
> the top Application.cfm file so that developers can check it out and include
> it in their working directory but not be able to commit it back to the
> repository.

Use the commitinfo hook and have it know that particular file should
never be allowed to be committed by normal developers. See the URL:
http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_18.html#SEC167 for
more information.

-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: set 1 file in repository to be read only

[Tumy, Brad]

So what it appears I would need to do using this method is have some sort of
regular expression search for the file name that is restricted.  If this
file name is found then it should return a non-zero exit status and the
commit on that file will fail.

Sounds complicated actually...maybe I am missing something.

Easier way?

Thanks.
Brad

-Original Message-
From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 4:03 PM
To: Tumy, Brad
Cc: [EMAIL PROTECTED]
Subject: Re: set 1 file in repository to be read only 


Tumy, Brad <[EMAIL PROTECTED]> writes:

> This question is more for a sanity check then anything else.
> 
> If I want one specific file in the repository to be read-only (to all
> developers) then I just set the permissions on that file (through OS
> [Solaris]) to be read-only ...correct? 

No.
 
> We are developing a web-application in Cold Fusion and I want to lock down
> the top Application.cfm file so that developers can check it out and
include
> it in their working directory but not be able to commit it back to the
> repository.

Use the commitinfo hook and have it know that particular file should
never be allowed to be committed by normal developers. See the URL:
http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_18.html#SEC167 for
more information.

-- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: set 1 file in repository to be read only

[Mark D. Baushke]

Tumy, Brad <[EMAIL PROTECTED]> writes:

> So what it appears I would need to do using this method is have some sort of
> regular expression search for the file name that is restricted.  If this
> file name is found then it should return a non-zero exit status and the
> commit on that file will fail.
> 
> Sounds complicated actually...maybe I am missing something.
> 
> Easier way?

The comminfo script is called on a particular directory given as the
pattern, it is not file-based. The arguments typically passed to the
script will include the name of the file and the directory in which it
resides. Check to see if the directory matches and the name of the file
matches and exit with a non-zero return code and the commit will not be
allowed.

This is sort of an abuse of the cvs system which is intended to allow
users to make changes to files they checkout of the repository...

Good luck,
-- Mark
 
> Thanks.
> Brad
> 
> -Original Message-
> From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 4:03 PM
> To: Tumy, Brad
> Cc: [EMAIL PROTECTED]
> Subject: Re: set 1 file in repository to be read only 
> 
> 
> Tumy, Brad <[EMAIL PROTECTED]> writes:
> 
> > This question is more for a sanity check then anything else.
> > 
> > If I want one specific file in the repository to be read-only (to all
> > developers) then I just set the permissions on that file (through OS
> > [Solaris]) to be read-only ...correct? 
> 
> No.
>  
> > We are developing a web-application in Cold Fusion and I want to lock down
> > the top Application.cfm file so that developers can check it out and
> include
> > it in their working directory but not be able to commit it back to the
> > repository.
> 
> Use the commitinfo hook and have it know that particular file should
> never be allowed to be committed by normal developers. See the URL:
> http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_18.html#SEC167 for
> more information.
> 
>   -- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: set 1 file in repository to be read only

[Tumy, Brad]

>This is sort of an abuse of the cvs system which is intended to allow
>users to make changes to files they checkout of the repository...

Is there a better to do this?
I want each developer to be able to have the entire project on their local
machines so that they can test from their local install of Apache and Cold
Fusion.  I don't want them to be able to overwrite this particular file
though.

Thanks,
Brad

-Original Message-
From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
Sent: Friday, June 06, 2003 4:36 PM
To: Tumy, Brad
Cc: [EMAIL PROTECTED]
Subject: Re: set 1 file in repository to be read only 


Tumy, Brad <[EMAIL PROTECTED]> writes:

> So what it appears I would need to do using this method is have some sort
of
> regular expression search for the file name that is restricted.  If this
> file name is found then it should return a non-zero exit status and the
> commit on that file will fail.
> 
> Sounds complicated actually...maybe I am missing something.
> 
> Easier way?

The comminfo script is called on a particular directory given as the
pattern, it is not file-based. The arguments typically passed to the
script will include the name of the file and the directory in which it
resides. Check to see if the directory matches and the name of the file
matches and exit with a non-zero return code and the commit will not be
allowed.

This is sort of an abuse of the cvs system which is intended to allow
users to make changes to files they checkout of the repository...

Good luck,
-- Mark
 
> Thanks.
> Brad
> 
> -Original Message-
> From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 4:03 PM
> To: Tumy, Brad
> Cc: [EMAIL PROTECTED]
> Subject: Re: set 1 file in repository to be read only 
> 
> 
> Tumy, Brad <[EMAIL PROTECTED]> writes:
> 
> > This question is more for a sanity check then anything else.
> > 
> > If I want one specific file in the repository to be read-only (to all
> > developers) then I just set the permissions on that file (through OS
> > [Solaris]) to be read-only ...correct? 
> 
> No.
>  
> > We are developing a web-application in Cold Fusion and I want to lock
down
> > the top Application.cfm file so that developers can check it out and
> include
> > it in their working directory but not be able to commit it back to the
> > repository.
> 
> Use the commitinfo hook and have it know that particular file should
> never be allowed to be committed by normal developers. See the URL:
> http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_18.html#SEC167 for
> more information.
> 
>   -- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Re: set 1 file in repository to be read only

[Mark D. Baushke]

Tumy, Brad <[EMAIL PROTECTED]> writes:

> >This is sort of an abuse of the cvs system which is intended to allow
> >users to make changes to files they checkout of the repository...
> 
> Is there a better to do this?

I am not able to think of any better way to do this.

> I want each developer to be able to have the entire project on their local
> machines so that they can test from their local install of Apache and Cold
> Fusion.  I don't want them to be able to overwrite this particular file
> though.

So, you want them to checkout the entire module or set of modules. Fine,
they can do that using cvs. If you want them to not be able to commit a
particular file, you need to instrument it with the hooks available. If
the cvs tool does not do what you need, then do not use it.

In any case, your developers could make local modifications of the file
that they do not checking to the system. Nothing prevents that at all.

Do you really have such a low opinion of your staff? Perhaps it is time
to either encourage management to hire new staff (may folks seem to be
looking for jobs in the current market), or perhaps you should consider
finding a place of employement where you can trust the staff around you
to do the right thing.

Good luck,
-- Mark

> Thanks,
> Brad
> 
> -Original Message-
> From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
> Sent: Friday, June 06, 2003 4:36 PM
> To: Tumy, Brad
> Cc: [EMAIL PROTECTED]
> Subject: Re: set 1 file in repository to be read only 
> 
> 
> Tumy, Brad <[EMAIL PROTECTED]> writes:
> 
> > So what it appears I would need to do using this method is have some sort
> of
> > regular expression search for the file name that is restricted.  If this
> > file name is found then it should return a non-zero exit status and the
> > commit on that file will fail.
> > 
> > Sounds complicated actually...maybe I am missing something.
> > 
> > Easier way?
> 
> The comminfo script is called on a particular directory given as the
> pattern, it is not file-based. The arguments typically passed to the
> script will include the name of the file and the directory in which it
> resides. Check to see if the directory matches and the name of the file
> matches and exit with a non-zero return code and the commit will not be
> allowed.
> 
> This is sort of an abuse of the cvs system which is intended to allow
> users to make changes to files they checkout of the repository...
> 
>   Good luck,
>   -- Mark
>  
> > Thanks.
> > Brad
> > 
> > -Original Message-
> > From: Mark D. Baushke [mailto:[EMAIL PROTECTED]
> > Sent: Friday, June 06, 2003 4:03 PM
> > To: Tumy, Brad
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: set 1 file in repository to be read only 
> > 
> > 
> > Tumy, Brad <[EMAIL PROTECTED]> writes:
> > 
> > > This question is more for a sanity check then anything else.
> > > 
> > > If I want one specific file in the repository to be read-only (to all
> > > developers) then I just set the permissions on that file (through OS
> > > [Solaris]) to be read-only ...correct? 
> > 
> > No.
> >  
> > > We are developing a web-application in Cold Fusion and I want to lock
> down
> > > the top Application.cfm file so that developers can check it out and
> > include
> > > it in their working directory but not be able to commit it back to the
> > > repository.
> > 
> > Use the commitinfo hook and have it know that particular file should
> > never be allowed to be committed by normal developers. See the URL:
> > http://www.cvshome.org/docs/manual/cvs-1.12.1/cvs_18.html#SEC167 for
> > more information.
> > 
> > -- Mark


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

RE: Help: Linux CVS Server Access Problem

[Robert Clark]

On Fri, 2003-06-06 at 11:25, Hill, Benjamin W wrote:
> ...but when I enter a password I get:
> 
> "cvs [login aborted]: connect to [SERVERNAME]([SERVERNAME]):2401 failed: No
> connection could be made because the target machine actively refused it."
> 

Some ideas 

Since you are running CVS through tcpd, make sure you have the
appropriate entries in /etc/hosts.allow.

Also check the system logs on the server, specifically
/var/log/messages, /var/log/secure and /var/log/syslog if they exist,
for any clues why the connection was rejected.

- Rob



___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs