Re: problem with pserver

[Hamish Allan]

Hi,

Unless the '/cvs_repository' in $CVSROOT is '/home/cvs/prj', your
connection will be refused in this way (because of the --allow-root
argument to cvs pserver).

HTH,
Hamish

"Grzegorz ?y?a" <[EMAIL PROTECTED]> wrote in message news:...
> hi.
> I have a problem, when i try to connect to pserver.
> 
> i type:
> cvs -d :pserver:user@server:/cvs_repository , type password and 
> 
> cvs [login aborted]: connect to server:2401 failed: Connection refused.
> 
> i have following entries:
> 
> 
> pserver2401/tcp pserver
> pserver2401/udp pserver
> 
> 
> 
> 
> service pserver
> {
>disable = no
>socket_type = stream
>protocol = tcp
>port = 2401
>wait = no
>user = root
>   server = /usr/bin/cvs
>   server_args = -f --allow-root=/home/cvs/prj pserver
> }
> 
> 
> thanks for any suggestion.
> 
> Greg
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs

Segmentation Fault (was Re: CVS sticky information ignored on import)

[Hamish Allan]

Thanks Greg.

> 'cvs import' does not "work" from within a working directory (aka
> sandbox) -- i.e. it does not do anything special.
> 
> Or rather it only works by virtue of the fact that by default it'll
> ignore all the administrative "CVS" sub-directories and the files they
> contain.

Ah, the tantalising 'by default'... I was hoping there would be some
way to persuade CVS to use the sticky data from the administrative
"CVS" sub-directories for the import. After all, the command does take
kflags and release tags as arguments!

I have ended up using the following instead:

find . -name Entries | xargs grep "/-kb/" \
  | sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||" \
  | xargs cvs -d $CVSROOT admin -kb

Actually that's not true, because if there are any files marked -kb in
the sandbox which are not imported because they're on the default CVS
ignore list, the admin command SIG_SEGVs.

Hence I've copied this to the gnu.cvs.bug list; if anyone is
interested, I can give you the exact script I'm running and the
sandbox source tree I'm running it on (which is
ftp://ftp.mozilla.org/pub/mozilla/releases/mozilla0.9.8/src/mozilla-source-0.9.8.tar.bz2
BTW).

For archive purposes, if anyone else is trying to do the same thing I
circumvented the segfault problem by creating an 'ignore' list from
the original import (| grep "^I " | grep -v "CVS$" >> $CVSIGNORELIST)
and then

for i in $(find . -name Entries | xargs grep "/-kb/" \
  | sed -e "s|CVS/Entries:/||" -e "s|/[^/]*/[^/]*/-kb/.*||");
  do grep $i $CVSIGNORELIST || cvs -d $CVSROOT admin -kb $i; done

If anyone can think of a better way to determine which files not to
admin (e.g., using an exit code from cvs to determine whether the file
is in the repository) I'd love to know.

thanks,
Hamish

p.s.
> Unless you're managing third-party sources you shouldn't use "cvs import".

Unfortunately that's what I'm doing!

> However if you're managing third-party binary files and checking them
> out on non-unix-ish platforms then you will have to individually ensure
> that the '-kb' flag is set in the RCS files in your own repository for
> every binary file (but not for text files if you want proper text
> handling to work!).

Unfortunately that's also what I'm doing!

> If you're doing the latter a lot then you might be better off using
> something other than CVS.

Well... mozilla uses CVS, and whatever I used I'd need to
differentiate between text and binary files.

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

CVS sticky information ignored on import

[Hamish Allan]

Hi,

I'm a newcomer to CVS so please forgive me if the answer to this
question is obvious. I have tried to find an answer in the FAQs and
the Cederqvist but without success.

It seems to me that if a file is marked as binary or tagged in
CVS/Entries in a sandbox, e.g.:

/noodle.jpeg/1.1/Mon Apr 8 16:39:14 2002/-kb/TNOODLE_FINAL

when 'cvs import'ed to a new repository, the resulting version should
be tagged and registered as binary, so that when you 'cvs checkout' it
again the resulting sandbox has the same binary/tag information.

However! This doesn't happen for me. I am using a straight 'cvs
import' with no extra arguments, and a straight 'cvs checkout' to get
the file back. I think it's the import which is losing the
information, as the file 'noodle.jpeg,v' makes no reference to
'NOODLE_FINAL' and the line just before what seems to be the binary
contents of the file reads 'text'. Incidentally, this is also the case
if I explicitly try to import the file '-kb'.

Can anyone tell me what I'm doing wrong? I appreciate that I might be
able to get it to work by putting *.jpeg in my cvswrappers file but
I'd like to know whether I'm missing something fundamental.

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