Re: PROPOSAL: Addressing the list's spam issue

[Russ Tremain]

Yes, please.  Sounds like a very reasonable plan.
Thank you very much for addressing this.

-Russ Tremain

>On Monday, April 8, 2002 at 13:58:15 (-0400), R P Herrold wrote: ]
>Subject: PROPOSAL: Addressing the list's spam issue
>
>Proposal: I propose to undertake to offer to moderate. If so
>designated, in moderating, my moderation will initially
>consist of turning on the option to catch and hold, pending
>discard, all non-subscriber posts.  I seek to manage held
>posts at least daily, often a couple times during the day (a
>subscriber's posts would continue to go straight thru ...)
>
>All HTML, non-English (within the bounds of non-English
>speakers' good faith efforts), and spam will be silently
>discarded.  Posters who post non-conformant meeting the
>foregoing criteria will be silently unsubscribed.
>
>Qualifications: I manage/moderate and admin several local
>lists, and moderate/admin the rpm-list over at Red Hat
>
>-- "CVS developers" -- How say you?

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

Re: Flat and hierarchical mirrors of repository

[Russ Tremain]

if everyone uses checkout to update, your design will work okay.
see the cederqvist manual on the difference between checkout
and update.
-Russ


At 4:50 PM -0700 5/1/01, Brian Jung wrote:
>Hi,
>
>   I'm a newbie setting up CVS locally for a group of
>designers who are used to writing code in a "flat" directory
>structure, e.g., src/*.c. Most of their tools assume this flat
>structure. As Murphy's law would have it, other groups we are working
>with prefer the hierarchical tree structure, e.g., moduleA/src/A*.src,
>moduleB/src/B*.c, etc., for their code. My goal is to be able to
>satisfy both crowds.
>
>   Starting with a "flat" repository structure, I can checkout
>a flat mirror (duh). Using the "modules" file in CVSROOT (ampersand),
>I can create subdirectories which can be checked out in local
>directories. However, a global update fills each subdirectory's src
>directory with all the *.src files. I assume I'll have to create a
>script for "update" when I'm doing it heirarchically that goes down
>each subdirectory (to my limit specified in "modules") and do a
>'checkout module'.
>
>   Do any of you have experience with this sort of thing? I
>realize it may be a newbie question and I couldn't find anything with
>my search of the archives. Any suggestions you have, based on your
>insight or experience, I would appreciate.
>
>   I may need to convince my local designers to break their
>code into modules with hierarchy and just make links to a flat
>directory. Or is it fairly straightforward to start with a
>hierarchical repository and create a "flat" mirror (without any
>links)?
>
>Thanks,
>   Brian Jung
>
>___
>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: Can the -D option be used on a branch?

[Russ Tremain]

At 4:24 PM -0700 4/12/01, Larry Jones wrote:
>Russ Tremain writes:
>> 
>> you can use -D with -r , but sometimes it is confusing.
>> if  is a simple tag, and not a branch tag, you might
>> not get what you expect.
>
>If you specify both a specific revision and a specific date, I don't see
>how you would know *what* to expect.
>

exactly.

IMHO, the semantics for -r are confusing.  Sometimes
it means a branch, and sometimes it means an exact revision.

I.e.:
-r  -D 

is useful, whereas:

-r   -D 

is nonsense.

-Russ



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

Re: Can the -D option be used on a branch?

[Russ Tremain]

you can use -D with -r , but sometimes it is confusing.
if  is a simple tag, and not a branch tag, you might
not get what you expect.

-Russ

At 10:56 PM -0700 4/11/01, David L. Martin wrote:
>> David L. Martin writes:
>> > 
>> > I'd like to be able to checkout from a branch but take revisions that
>> > are older than a specified date.  Since the -D and -r are both
>> > sticky, they apparently cannot be used in combination.  Does
>> > anyone know of a workaround or combination of commands to
>> > do this?
>> 
>> Actually, they can be used in combination.
>> 
>> -Larry Jones
>> 
>
>Ah yes, so they can!  The tag is sticky, not the date, in the resulting
>checkout, but the date option is honored as expected.  The command
>usage for checkout and update (cvs --help co, cvs --help up) should
>perhaps be changed from [-r rev | -D date] to [-r rev] [-D date] to indicate
>that both options may be used in combination.
>
>In contrast, I note that rtag and tag operations do not accept the
>combination of -r and -D options.  They are mutually exclusive, and
>the help for rtag and tag indicates this ([-r rev | -D date]).  It would be
>nice for tag/rtag to accept both options as well.  (But one could always
>tag following checkout with both options and achieve essentially the
>same result).
>
>Thanks,
>David Martin
>
>
>___
>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: CVS bashing?

[Russ Tremain]

At 5:21 PM -0700 4/11/01, Paul Sander wrote:
>All of the points made in that page are right on.  I can go on to say more:
>
>- The modules database isn't versioned, which can affect reproducibility
>  requirements.

I think that this is an important point to reinforce.

basically, if you add a target to a definition for one release,
you need to keep it forever.

i.e.

suppose "releaseone" has:

foomodule   -a aa bb cc dd

you branch it and move on.  in "releasetwo" you delete dd.

you cannot delete dd from the module def, or you
break foomodule in releaseone.

one way around this is to create a naming convention
for the module defs, i.e.,

foomodule_releaseone-a aa bb cc dd

foomodule_releasetwo-a aa bb cc

and adjust your versioned build scripts accordingly.

this prevents cvs from having to consider dd for releasetwo.

-Russ



>- The *info files accept a comprehensive list of sources on their command
>  lines, limiting their scalability.  (After a branch merge on a very large
>  project, the command line buffer of the shell invoking the *info file
>  can overflow, causing breakage.)
>- Triggers registered via the modules database are sometimes persistent,
>  causing suprises after modifications.
>- The history file grows without bound, and can't be managed in any natural
>  way.
>
>I'm sure I can go on if I think about this for a few minutes...
>
>--- Forwarded mail from [EMAIL PROTECTED]
>
>Someone brought up a site on another mailing list about CVS and its
>limitations and was citing this as a reason to not use CVS...what do you
>all think about this?  Some of this stuff I have personally witmessed
>(i.e. large binary file problem, no directory versioning)  but I'm
>curious as to others opinions...
>
>http://www.snuffybear.com/scm_grind_cvs.htm
>
>--- End of forwarded message from [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: DOS EOL pollution in repository

[Russ Tremain]

At 3:51 PM -0800 3/14/01, Jerry Nairn wrote:
>
>
>> From: David L. Martin [mailto:[EMAIL PROTECTED]] 
>> Sent: Wednesday, March 07, 2001 10:36 PM 
>
>
>> Commented out from the script is an alternative 
>> "automatic" way to determine whether the file 
>> is ASCII using the Unix file command.  I haven't 
>
>
>A better way of doing this is with "cvs -n log -h". One line of the output will be 
>"keyword substitution: kv" 
>for all of the files which cvs is treating as text. 
>If you're doing some funny things, you might want to allow this check on some other 
>keyword substitution modes, like kvl. Certainly you would never run this check on 
>anything with mode b.
>
>
>Sorry I'm so far behind in reading this group. 


thanks, good suggestion.  shouldn't even look at
anything with mode b, and this would provide
a way for someone to create a file with DOS EOL
conventions by intent.

-Russ



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

RE: WinCVS incorrectly showing locally modified files

[Russ Tremain]

At 11:34 AM -0800 3/8/01, [EMAIL PROTECTED] wrote:
>Content-Type: text/plain; charset=US-ASCII
>Content-Disposition: inline
>   ;Creation-Date="Thu, 8 Mar 2001 13:34:07 -0600"
>Content-Transfer-Encoding: 7bit
>
>
>> One thing that will cause this is if you have users that
>> commit files with DOS EOL characters.  I believe the sequence is this:
>> 
>> 1.  in wincvs or upon cygwin installation, select the option to
>> preserve unix EOL conventions.
>
>I have this set for both cygwin and WinCVS. My interpretation of this 
>is that when a file gets checked out, it will get checked out without 
>the ^M's. Is this correct?

yes.  basically, CVS will leave the files alone.  Normally, it will
convert text files to "native" format.

>> 2.  edit the file using a DOS editor that bullies the file into
>> DOS EOL conventions.
>
>It is true that you could use a text editor that re-inserts the ^Ms, 
>but when you commit the file to a server running on a remote unix host, 
>won't the ^M's be removed, that is, unless the file was checked in this 
>the binary option.

I think this depends on your settings in step #1.  If you selected
this option, I don't think cvs will do the conversion.  It expects
that you are keeping all files in unix format.

>> 3.  commit the file.
>> 4.  the file is now in the repository with ^M's
>> 5.  user2 does an update, with the same wincvs setup.
>> 6.  user2 sees a merge conflict, with the contents of the
>> entire file.
>
>An interesting note is that I wasn't seeing this problem until after I 
>upgraded to WinCVS 1.2. Unfortunately, I can't see for sure that this 
>is the cause of the problem because at around the same time, I also 
>deleted and freshly installed cygwin.
>
>I'm not sure that I mentioned this. When I invoke "cvs update" from the 
>command line, no files are listed as locally modified.

well, this may be a different problem.  We are seeing this also.
I was describing the merge conflict problem we are seeing.

Wonder if cygwin is doing a translation post-wincvs, so that
cvs thinks the files have been modified?

I guess the thing to do is to check to see if the files
that are showing up as modified have ^M's in the repository.
Perhaps this is unrelated to the ^M problem.

>Another thing. If, from WinCVS, I update any of these files that are 
>being incorrectly identified as modifed, the problem goes away, i.e. 
>the file appears as up-to-date. If I look in the WinCVS log window, 
>nothing got updated.
>
>I'm still needing help. Thanks

you and me both...

-Russ



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

Re: WinCVS incorrectly showing locally modified files

[Russ Tremain]

At 10:25 AM -0800 3/8/01, [EMAIL PROTECTED] wrote:
>Content-Type: text/plain; charset=US-ASCII
>Content-Disposition: inline
>   ;Creation-Date="Thu, 8 Mar 2001 12:25:20 -0600"
>Content-Transfer-Encoding: 7bit
>
>WinCVS version 1.2 is incorrectly reporting that cvs controlled files 
>are locally modified. Interesting it only does this for some files and 
>not others. To check out files, I'm using the version of cvs.exe that 
>comes with cygwin (version 1.11). Any help is greatly appreciated. 


One thing that will cause this is if you have users that
commit files with DOS EOL characters.  I believe the sequence is this:

1.  in wincvs or upon cygwin installation, select the option to
preserve unix EOL conventions.
2.  edit the file using a DOS editor that bullies the file into
DOS EOL conventions.
3.  commit the file.
4.  the file is now in the repository with ^M's
5.  user2 does an update, with the same wincvs setup.
6.  user2 sees a merge conflict, with the contents of the
entire file.

-Russ
 
P.S.  Wonder how many person years have been wasted on this
  little problem since 1981?



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

Re: DOS EOL pollution in repository

[Russ Tremain]

David -
thanks a lot!  I'll try it out.
I was thinking of using cvswrappers to decide on
the binary property, since we maintain this.
Otherwise, off into binary-file-detection-hueristics land.
-Russ


At 10:35 PM -0800 3/7/01, David L. Martin wrote:
>> > I'm tempted to put in a commit
>> > filter that rejects text files with DOS EOL's.
>> 
>> Sounds like a good thing to do in addition.  My suggestions will
>> make life easier for people, but this is what'll enforce your
>> policy.
>> 
>I've attached a perl script callable from commitinfo
>that rejects commits of certain file types if any line
>in the file ends in ctrl-M.
>
>This script contains an explicit list of end of filename
>matching criteria to ascertain whether a file is an
>ASCII file.  (e.g. .java$, .txt$, .html$, etc.) and should
>be checked for lines ending with ctrl-M.  (You
>certainly would *not* want to run this check on
>a binary file.)
>
>Commented out from the script is an alternative
>"automatic" way to determine whether the file
>is ASCII using the Unix file command.  I haven't
>thoroughly tested it, but I've found that if it returns
>a match of ":.*text" or ":.*script", it is likely an
>ASCII file.
>
>Hope this helps,
>David Martin
>
>
>
>Content-Type: application/octet-stream;
>   name="commit_prep.pl"
>Content-Disposition: attachment;
>   filename="commit_prep.pl"
>
>Attachment converted: axl-usr:commit_prep.pl (/) (1286)




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

DOS EOL pollution in repository

[Russ Tremain]

Hello -

We are getting ^M's in our repository now and then, and
wondered how other folks deal with this problem.

One source of the problem is folks editing files on NT,
and then copying them to unix to commit them.

Another source seems to be from cygwin, which gives you
the choice of keeping NT files in DOS format or unix format.
So some folks seem to be checking out files in unix format,
editing them in some editor that converts them to DOS format,
and then integrating them, polluting the RCS files
with the DOS EOL conventions.

When other folks update on NT, they then get a merge conflict for the
whole file, even if they have not modified it.

Suggestions?  Remedies?  I'm tempted to put in a commit
filter that rejects text files with DOS EOL's.

thanks,
-Russ



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

perl pserver client?

[Russ Tremain]

Hi -

Is anyone aware of a perl pserver client for cvs?
I'm interested in this for a reporting hook.

thanks for any pointers...

-Russ



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

Re: 'cvs update' skipping directories

[Russ Tremain]

At 1:11 PM -0800 1/30/01, Larry Jones wrote:
>Peter Schuller writes:
>> 
>> Basically, if I do a check-out I get everything. But if someome else then
>> adds a directory I sometimes (but not always) won't get a copy of that
>> directory when doing "cvs update".
>
>Update doesn't get new directories by default, you need to use the -d
>option.  (The reason is that CVS doesn't have any way to tell the
>difference between a newly added directory and an old one that you
>explicitly didn't checkout.)  If you want that behavior all the time,
>you can add it to your ~/.cvsrc file.
>
>-Larry Jones

I would add that if you have defined a module that organizes
your working directory structure differently than in your
repository, then update -d won't work either.  If a directory is
added to the module definition later, update -d won't always
find it.

update only knows about directory and file names, not module names.

however, you can always say "cvs co " to get new directories.
A checkout will update existing files in your working dir the second time,
and will add any new directories.

If you provide a module alias for each top-level directory
in your repository, then you can always "cvs checkout" to
create OR update your top-level directories, and get consistent
semantics that intermix cleanly with more esoteric module definitions.

This seems easier to me.

-Russ



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

Re: cvs pserver performance

[Russ Tremain]

At 8:58 AM -0800 1/25/01, Larry Jones wrote:
>Russ Tremain writes:
>> 
>> At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
>> >
>> >I recommend mounting /tmp on some sort of memory-based filesystem for
>> >maximum performance - this made a big difference on apache.org.
>> 
>> thanks.. this is the next step; unfortunately, have to upgrade
>> memory first.
>> 
>> Also, hard to know how big to make this device; I'm planning on
>> 1 GB, and then writing a cron job to clean up left-over server
>> tmp dirs.
>
>There shouldn't be any left-over server directories unless the server
>crashes or encounters a serious error.  Is this just general caution, or
>have you had an actual problem with left-over directories?

I have, but I think these occur when the client doesn't close down the
connection to the server properly.  Sometimes I have pserver process
that hangs around for a couple of days, and I (or someone else)
kills these off by hand with kill -9.  This will leave the server
directory around.  A normal kill seems to clean up after itself.

Not sure why the connections don't close down on the server... when
I truss them they are waiting on a read.  This is with 10.1.8, so
perhaps when I upgrade to 1.11, these problems may go away.

BTW, in terms of the solaris memory based filesystem (I do work
for Sun, after all :-), the solution is pretty simple:

# mount -F tmpfs -o size=512m vmem /cvstmp

will create and mount a 512 MB "ram" disk (actually, a virtual memory
based ram disk, the way I read the man page, meaning it is backed
up by swap).  The identifier "vmem" can be whatever you want df
to report as the name of the device.

This really helps pserver performance on updates.  Here are
the results of some tests run on a Sun ultra 60 with a single disk drive
(time is elapsed time for each process in minutes; all tests run
on same machine as the pserver):

+---+---+---+
|what   | UFS /tmp  | tmpfs /tmp|
+---+---+---+
| 1 update:  2321 dirs, |   |   |
|12,333 files   |   14:11   |3:42   |
+---+---+---+
| 2 updates, per update |   37:36   |8:07   |
+---+---+---+
| 3 updates, per update |   57:08   |14:50  |
+---+---+---+
| cp -r of working dir  | 11:33 |
+---+---+
| Size of working dir   | 117MB |
+---+---+

Update times are averaged for the multiple update tests.

Note that these updates are against a static repository,
so they are not moving any data to the client.  This means
that almost all of the i/o is reading from the repository
and writing to the tmp directory, which is similar to a
real pserver environment, minus any network i/o.

As a additional test, I added a small tmpfs for the cvs
locks directory and re-ran the 3-update test:

+---+---+
|what   |  tmpfs /tmp + tmpfs /locks|
+---+---+
| 3 updates, per update |   3:57|
+---+---+

The 350% improvement over just /tmp on tmpfs is perhaps a bit
artificial, given that all three processes were started at the
same time. One would expect that this would lead to more
contention for locks than normal. More testing would be needed
to suss this out.

Overall, however, the results are fairly astonishing using
tmpfs for both cvs /tmp and locks - a 1400% improvement over
a simple UFS approach. 

I would recommend at least 500Mb for the cvs tmp directory -
more if you have the memory and are supporting lots of
concurrent users.  In reading the man page, it seems you
have to be careful about some of the limits.  In particular,
the number of files & directories you can allocate is
dependant on how big your physical memory is, even though
you can increase the size of tmpfs by increasing the amount of
swap space.  This limit is important in CVS because it
creates a lot of directories & files.  I ran into problems
on a machine with 512MB, but seemed okay on a 1GB machine.

Not sure how this limit is calculated...

-Russ

>A good alternative to the memory based filesystem is a disk based
>filesystem that supports soft updates (even better than a virtual memory
>based filesystem, not quite as good as a physical memory based
>filesystem but a much more efficient use of resources).  If neither of
>those are viable alternatives, you can at least mount /tmp asynchronous
>if your

Re: cvs pserver performance

[Russ Tremain]

At 4:48 PM -0800 1/24/01, Brian Behlendorf wrote:
>On Wed, 24 Jan 2001, Russ Tremain wrote:
>> So we created a new device that was tuned for performance,
>> and mounted it on the /tmp used by the pserver.  
>
>I recommend mounting /tmp on some sort of memory-based filesystem for
>maximum performance - this made a big difference on apache.org.
>

thanks.. this is the next step; unfortunately, have to upgrade
memory first.

Also, hard to know how big to make this device; I'm planning on
1 GB, and then writing a cron job to clean up left-over server
tmp dirs.

-Russ




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

Re: cvs pserver performance

[Russ Tremain]

Just to close out this topic, our performance problems
were not related to network performancel  The excessive
TCP-level retransmits that I had seen earlier was
a transient problem over our WAN.

The problem was all disk i/o, primarily in the tmp device
that was being used by the pserver.

I found this out initially by going into the cold room
and listening to the machine.  The disk array was
hammering away like an old coffee grinder, with only
one pserver process running.

Part of the problem was the way the disk array was
set up to mirror all writes.  It was not tuned
for performance.

So we created a new device that was tuned for performance,
and mounted it on the /tmp used by the pserver.  This
improved performance greatly, especially for simultaneous
accesses.  We can now support several simultaneous updates
without the significant performance degradation I described
earlier.

When someone does a full update against our large repository,
each pserver process creates some 6500 directories in /tmp
and writes some 7500 files.  This is a copy of the directory
structure of the repository and the CVS/ meta files from the
client.  Then it compares this against the repository in order
to calculate the diffs that need to be sent to the client.

This is why the /tmp device must be as fast as possible.

If you have a large repository, with a large development
organization, it is hard to see how a pserver can ramp up
without some strategy whereby you give each pserver
a fast /tmp device.

Regards,
-Russ


At 2:38 PM -0800 1/10/01, Russ Tremain wrote:
>At 1:35 PM -0800 1/10/01, Larry Jones wrote:
>>Russ Tremain writes:
>>> 
>>> We are running cvs 1.10.8 as a pserver on a rather beefy
>>> solaris system.  Our repository is fairly large and contains
>>> about 45,000 files.  This machine is idle most of the time,
>>> and its only job is to run the CVS server.
>>
>>There were a bunch of memory leaks in 1.10.8 that were fixed in 1.11
>>which could well cause the server process to grow very large and start
>>thrashing when checking out or updating that many files.  Upgrading may
>>help your performance and I'd recommend it in any case.
>
>good suggestion... I will try this.
>
>>> When I snoop on the ethernet interface, I find that all clients
>>> are sending to the server port 2401.
>>> 
>>> I was surprised by this, since most servers only listen on
>>> a well-known socket for connections, negotiate a private socket
>>> to handle a particular client, and then use this new socket for
>>> further communications.
>>
>>You're confusing ports with sockets.  A socket is identified by the
>>local host address, the local port number, the remote host address, and
>>the remote port number.  Most servers work the same way CVS does: they
>>listen on a well-known *port* for connections; when they accept a
>>connection, they get a private *socket* that is used for further
>>communication.  That socket still has the well-known local port, but
>>each such socket has a different remote address/port.
>
>ahh... yes, so I was.  so inetd just opens a socket and cvs inherits
>this open file descriptor, and then inetd's job is done.  The kernel
>is now able to route all packets that come in on this socket to
>the process with the open file descriptor, which is now cvs.
>
>>> My understanding is that if a bunch of processes are reading
>>> the same socket, then the packet is consumed by the first
>>> reader.
>>
>>That is correct, but each CVS server has a unique socket (they just all
>>have the same local port number).
>>
>>> Therefore, the retransmits would make sense as a source of the
>>> poor performance we are experiencing when we have multiple
>>> updates running.
>>
>>If you're dropping network packets, you either have a network problem or
>>the server is badly overloaded.  You need to identify where the packets
>>are getting dropped and, if it's the server, you need to do some
>>performance analysis on it to discover the problem.  The O'Reilly book
>>on System Performance Tuning is a good place to start (www.ora.com).
>
>I don't think it is a network problem per se, since I believe I can
>duplicate it on a system without using the network.  But I need
>to do some work here to set up a test.  (we had another system
>demonstrating similar characteristics when all the updates were
>local processes).
>
>Another wrinkle that I didn't mention is that we use a perl script
>to do a chroot and handle the overflow "--allow-root" args, so
>this could be causing problems as well.
>
&g

Re: cvs pserver performance

[Russ Tremain]

At 1:35 PM -0800 1/10/01, Larry Jones wrote:
>Russ Tremain writes:
>> 
>> We are running cvs 1.10.8 as a pserver on a rather beefy
>> solaris system.  Our repository is fairly large and contains
>> about 45,000 files.  This machine is idle most of the time,
>> and its only job is to run the CVS server.
>
>There were a bunch of memory leaks in 1.10.8 that were fixed in 1.11
>which could well cause the server process to grow very large and start
>thrashing when checking out or updating that many files.  Upgrading may
>help your performance and I'd recommend it in any case.

good suggestion... I will try this.

>> When I snoop on the ethernet interface, I find that all clients
>> are sending to the server port 2401.
>> 
>> I was surprised by this, since most servers only listen on
>> a well-known socket for connections, negotiate a private socket
>> to handle a particular client, and then use this new socket for
>> further communications.
>
>You're confusing ports with sockets.  A socket is identified by the
>local host address, the local port number, the remote host address, and
>the remote port number.  Most servers work the same way CVS does: they
>listen on a well-known *port* for connections; when they accept a
>connection, they get a private *socket* that is used for further
>communication.  That socket still has the well-known local port, but
>each such socket has a different remote address/port.

ahh... yes, so I was.  so inetd just opens a socket and cvs inherits
this open file descriptor, and then inetd's job is done.  The kernel
is now able to route all packets that come in on this socket to
the process with the open file descriptor, which is now cvs.

>> My understanding is that if a bunch of processes are reading
>> the same socket, then the packet is consumed by the first
>> reader.
>
>That is correct, but each CVS server has a unique socket (they just all
>have the same local port number).
>
>> Therefore, the retransmits would make sense as a source of the
>> poor performance we are experiencing when we have multiple
>> updates running.
>
>If you're dropping network packets, you either have a network problem or
>the server is badly overloaded.  You need to identify where the packets
>are getting dropped and, if it's the server, you need to do some
>performance analysis on it to discover the problem.  The O'Reilly book
>on System Performance Tuning is a good place to start (www.ora.com).

I don't think it is a network problem per se, since I believe I can
duplicate it on a system without using the network.  But I need
to do some work here to set up a test.  (we had another system
demonstrating similar characteristics when all the updates were
local processes).

Another wrinkle that I didn't mention is that we use a perl script
to do a chroot and handle the overflow "--allow-root" args, so
this could be causing problems as well.

At any rate, I'm relieved to hear that that my original hypothesis
was *completely* wrong.. :)

Thanks for your help... I will report back what I find out
to the list.

-Russ


>-Larry Jones
>
>Buddy, if you think I'm even going to BE here, you're crazy! -- Calvin
>
>___
>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

cvs pserver performance

[Russ Tremain]

Hi -

I've reviewed much of the discussion on this list on
CVS server performance, in hopes of finding something related
to the problems we are experiencing our CVS server.  So far, I
haven't found anything similar to what we are experiencing.
Apologies if this is a re-hash.

We are running cvs 1.10.8 as a pserver on a rather beefy
solaris system.  Our repository is fairly large and contains
about 45,000 files.  This machine is idle most of the time,
and its only job is to run the CVS server.

Performance is adequate when one client does a full CVS update.
This update takes 15-20 minutes.

When a second client updates, both updates slow substantially,
taking about 35-40 minutes.

When three clients are updating simultaneously, the update
time starts to climb to about 1.5 hours per client.

Surprisingly, the packet traffic goes *down* as more clients
attach.

When a truss a client that is particularly slow, I find
that it is loosing, (and therefore requesting a retransmit of,)
about every third packet.

When I snoop on the ethernet interface, I find that all clients
are sending to the server port 2401.

I was surprised by this, since most servers only listen on
a well-known socket for connections, negotiate a private socket
to handle a particular client, and then use this new socket for
further communications.

My understanding is that if a bunch of processes are reading
the same socket, then the packet is consumed by the first
reader.

Therefore, the retransmits would make sense as a source of the
poor performance we are experiencing when we have multiple
updates running.

Tell me it isn't true...

If it is true, then is there an easy work-around?  I would like to
retain the pserver strategy...but I suppose we could revert to NFS
for subsets of clients.

Thanks for any help or suggestions...

Regards,
-Russ

Russ Tremain
[EMAIL PROTECTED]

Senior Architect, Infrastructure Engineering
Forte Tools Division
Sun Microsystems, Inc.



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