Re: Question about process scheduleing

2004-08-26 Thread Andrew Thomas
Lynch, Harold wrote:
I'm trying to look into a problem with the amount of time it takes us to 
do a checkout of a large (800 meg) module.

On most of the machine in the shop it takes between 10 and 15 minutes, 
on one machine it can take an hour.

When I look at top on the cvs server, the process associated with the 
pulls to that machine get very little cpu.
Is there any kind of scheduling going on inside the cvs server process 
(aside from blocking for io)?
I had a problem like this that ultimately turned out to be a network 
card misbehaving, particularly with ssh.

Andrew Thomas

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


CVS 1.12.9 breaks emacs pcl-cvs mode - known bug?

2004-08-26 Thread Andrew Thomas
Hello all,
The latest version of CVS, version 1.12.n (n>5), changed the format of
its output on commit messages.  This unfortunately breaks pcl-cvs mode
in emacs, which uses the commit messages to determine which files have
been committed.  It is of course possible to alter pcl-cvs to parse
the new messages, but the new messages produced by CVS no longer
contain sufficient information for a front-end to be able to determine
what has happened.  CVS needs to be altered slightly to produce
sufficient information so that front-end programs can function.  I'll
clarify below, but my question is: Is this a known bug, and is there
any plan to fix it?
Cheers,
    Andrew Thomas
--- The problem in more detail ---

First, the way it used to work:
===
andrew:~$ cvs -v
Concurrent Versions System (CVS) 1.12.5 (client/server)
Copyright (c) 1989-2003 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS

This is the structure of a the CVS repository:
==
andrew:~$ ls -R temp
temp:
CVSROOT  projects
temp/CVSROOT:
Emptydircommitinfo,v  cvswrappers,v  modulesrcsinfoval-tags
checkoutlistconfighistorymodules,v  rcsinfo,v  verifymsg
checkoutlist,v  config,v  loginfonotify taginfo 
verifymsg,v
commitinfo  cvswrappers   loginfo,v  notify,v   taginfo,v

temp/CVSROOT/Emptydir:
temp/projects:
project1  project2
temp/projects/project1:
module1
temp/projects/project1/module1:
main.c,v
temp/projects/project2:
module2
temp/projects/project2/module2:
main.c,v
I change main.c in two separate projects, and then perform a commit:

andrew:~/temp3$ cvs commit -m"test"
cvs commit: Examining projects
cvs commit: Examining projects/project1
cvs commit: Examining projects/project1/module1
cvs commit: Examining projects/project2
cvs commit: Examining projects/project2/module2
Checking in projects/project1/module1/main.c;
/home/andrew/temp/projects/project1/module1/main.c,v  <--  main.c
new revision: 1.2; previous revision: 1.1
done
Checking in projects/project2/module2/main.c;
/home/andrew/temp/projects/project2/module2/main.c,v  <--  main.c
new revision: 1.2; previous revision: 1.1
done
andrew:~/temp3$
** Notice that CVS produces four lines of output for each file,
   indicating the relative local path of the file on the first line,
   and then the repository file name and the basename of the local
   file on the second line.  pcl-cvs needs the relative local path on
   the first line (the "Checking in..." line) in order to determine
   which file was actually committed.
Now, the newer broken way:
==
andrew:~/temp3$ cvs -v
Concurrent Versions System (CVS) 1.12.9 (client/server)
Copyright (c) 1989-2004 Brian Berliner, david d `zoo' zuhn,
Jeff Polk, and other authors
CVS may be copied only under the terms of the GNU General Public License,
a copy of which can be found with the CVS distribution kit.
Specify the --help option for further information about CVS
Again, change both main.c files and commit:
===
andrew:~/temp3$ cvs commit -m"test"
cvs commit: Examining projects
cvs commit: Examining projects/project1
cvs commit: Examining projects/project1/module1
cvs commit: Examining projects/project2
cvs commit: Examining projects/project2/module2
/home/andrew/temp/projects/project1/module1/main.c,v  <--  main.c
new revision: 1.3; previous revision: 1.2
/home/andrew/temp/projects/project2/module2/main.c,v  <--  main.c
new revision: 1.3; previous revision: 1.2
andrew:~/temp3$
** Notice that CVS no longer produces the first and fourth lines of
   output.  The first line was the only one carrying the relative
   local path to the file being committed.  It is no longer possible
   for pcl-cvs to determine which file was committed.  It is not
   possible in general to "guess" the local file path from the
   repository file name since each directory has its own CVSROOT so
   that the repository organization is not necessarily anything like
   the local directory organization.  It is also not possible to use
   the "Examining " lines in the output since they all
   precede the first file commit message, so we still do not know
   which files belong to which directories.
Other programs acting as a front-end to CVS will also likely break
with this new reduced (insufficient) information.  WinCVS comes to
mind, though I have not tested it.
This whole problem could be trivially resolved in CVS by simply
altering the line:
/home/andre

Re: Question about RCS files

2004-08-26 Thread Andrew Thomas
K. Posern wrote:
But I need an exact copy of the version a CLIENT has in its
> /SOMEWHERE/sv dir on the SERVER (so without the rcs stuff).
How can I achieve this? Do I have to to do an cvs-checkout 
> on the server and cvs-update everytime a client did commit
> something?
Or can I say to the server somehow to keep automatically 
> the rcs stuff seperate in one dir and an "client-like-copy"
> of the cvs-repository in another dir?
You have to do a cvs-checkout into a separate directory on the server, 
and then perform a cvs-update every time a client does a commit.  In 
UN*X you can do the checkout on a cron job periodically.  In Windows I 
think you can use cygwin to set up a cron job as well.  You could also 
abuse the "loginfo" script so that after every commit the server runs a 
"cvs update" in you checked-out directory.  See 
https://www.cvshome.org/docs/manual/cvs-1.11.17/cvs_18.html#SEC167

Cheers,
Andrew Thomas

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