John Carter wrote:
On Fri, 11 Feb 2005, Michael Schiestl wrote:
Where the hell is the bottleneck? Is there a way to make CVS faster?
While I wouldn't called CVS slow, I would appreciate some hints on
optimizing / tweaking performance.
We're using version 1.11.1p1 via pserver on a
On Fri, 11 Feb 2005, Michael Schiestl wrote:
Where the hell is the bottleneck? Is there a way to make CVS faster?
While I wouldn't called CVS slow, I would appreciate some hints on
optimizing / tweaking performance.
We're using version 1.11.1p1 via pserver on a Redhat Linux version
2.4.17+acl on
Title: question about helping cvs performance.
I'm getting complaints from the users about the amount of time it takes to
do a tag or a branch (especialy the branch).
Are there any standard things that can be done, or to watch out for, that
would make these functions run as well
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Larry Jones wrote:
|a) Just what is an in-memory file system?
|
|
|Just what it says -- a filesystem where the data only exists in memory
|(rather than being written to a disk); they are commonly used for /tmp.
|If you're already using such a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
| The creation of cvs locks is a multi-step process that ends with a
| #cvs.lock directory being created for the duration of the lock and then
| being removed. For some operations, the creation of the read file, the
Just picking
On Tue, 2003-10-28 at 23:15, Mark D. Baushke wrote:
No, there are still multiple directories using a LockDir and a traversal
is still done. The difference is that the operations are typically
handled much faster.
snip lots of good stuff
Thanks much for the informative post. This is good info
Great info from everyone! Thank you -
Have one quick question right now, more comments later - and Mark, I'll get the problem with the current version of Eclipse and any cvs version of 1.11.7 and higher out as soon as I can.
As far as setting this LockDir to something like /tmp/CVSLockDir:
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Pfeiffer [EMAIL PROTECTED] writes:
Great info from everyone! Thank you -
Have one quick question right now, more comments later - and Mark, I'll
get the problem with the current version of Eclipse and any cvs version of
1.11.7 and higher
Richard Pfeiffer writes:
In our case, as a refresher, our repository is prod. level NFS mounted
on a dedicated NetApp disk and we have proven that in our case, this is
much faster. So:
1) Would it still be advisable to try writing lock files to the local
/tmp?
If your /tmp is on a
How is that increasing NFS traffic? You're still doing exactly the sameoperations, just in a different directory
I'm going to go look for my brain and I'll be back in 5 minutes.
Not sure what I was thinking here. Of course I knew that ;) -I'm just
typing a bit too fast!
Larry Jones [EMAIL
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Larry Jones wrote:
| It's probably worth a few words about locking details. Most operations
|
|lock a single directory at a time, which minimizes lock contention.
|Checkout is the notable exception, it locks the entire tree for the
|duration of the
Good Afternoon,
I have a few more questions related to performance. SomeMAY be a bit 'out-of-the-box, but please bare with me!
BASICS:
We are running cvs-1.11. I did migrate us to 1.11.9, but it turned out it does not mesh with Eclipse, which is what our developers use. The latest upgrade
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Pfeiffer [EMAIL PROTECTED] writes:
BASICS:
We are running cvs-1.11. I did migrate us to 1.11.9, but it turned out it
does not mesh with Eclipse, which is what our developers use. The latest
upgrade Eclipse can use is 1.11.6. From what
Richard Pfeiffer writes:
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Please do not send MIME and/or HTML encrypted messages to the list.
Plain text only, PLEASE!
We are running cvs-1.11. I did migrate us to 1.11.9, but it turned out
it does not mesh with Eclipse, which is
Mark D. Baushke writes [about locks on in-memory filesystems]:
If you are able to write to memory faster than to your repository, then
the difference in speed between those to mediums is how much faster you
will be able to create your lock. I would guess that in most cases of
a repository
Derek Robert Price writes:
_commit_ (not checkout) is the notable exception, with not-so-notable
exceptions being `cvs admin' and all of the watch commands.
Yes, that's what I meant. I can't imagine why my fingers typed
something different. :-)
-Larry Jones
It doesn't have a moral, does
Thank you very much, Larry and Eric, for the responses dealing with cvs performance issues, especially as they relate to branching. I believe I understand that branching speed is affected by a number of things, including:
1) the size of the project dir
2) where the branch is taking place
Richard Pfeiffer writes:
When the branch command is run, usually via Eclipse, the problem lies in
that the tags get created but the new branch creation sometimes fails.
I don't understand that statement -- as far as CVS is concerned,
creating the tags *is* creating the branch, there's
Good Afternoon,
We have been experiencing some slow cvs performance and I had a few quick questions to see if either of these would have any bearing (some of the project directories in the repository are rather large, 357 Mb, etc)
1) If we have multiple users sharing the same userid, would
On Tue, Oct 21, 2003 at 02:10:46PM -0700, Richard Pfeiffer wrote:
(some of the project directories in the repository are
rather large, 357 Mb, etc)
1) If we have multiple users sharing the same userid, would
that create any kind of locks, etc, that could hinder co/ci
times?
Locks are
Richard Pfeiffer writes:
1) If we have multiple users sharing the same userid, would that create
any kind of locks, etc, that could hinder co/ci times?
Not that I can think of.
2) There is a great deal of branching taking place, and it has come to
my attention that there are some old
Vivek Venugopalan writes:
We have a 2 GB repository running on a Linux system for over an year. It
has a few thousand files (approx 10,000 ) and has started progressievly
become very slow. We have a lot of tags (daily builds with a tag for each
build) and a few branches ( 10). Can you
[ On Saturday, March 29, 2003 at 08:34:13 (+0530), Vivek Venugopalan wrote: ]
Subject: Improving CVS Performance?
We have a 2 GB repository running on a Linux system for over an year. It
has a few thousand files (approx 10,000 ) and has started progressievly
become very slow. We have
Hello
We have a 2 GB repository running on a Linux system for over an year. It
has a few thousand files (approx 10,000 ) and has started progressievly
become very slow. We have a lot of tags (daily builds with a tag for each
build) and a few branches ( 10). Can you folks suggest what are
Michael Peck writes:
I also discovered that as the history file (CVSROOT/history) grows, it
really becomes a HUGE bottleneck.
If you delete/rename the file, cvs will stop appending to it.
As of CVS 1.11, you can also set LogHistory in CVSROOT/config to only
record events that you're
: Re: CVS Performance
Michael Peck writes:
I also discovered that as the history file (CVSROOT/history) grows, it
really becomes a HUGE bottleneck.
If you delete/rename the file, cvs will stop appending to it.
As of CVS 1.11, you can also set LogHistory in CVSROOT/config to only
record events
It appears we have a performance problem within our CVS system. We are
not able to make use of more then approximately 5% of the CPU on an
overall basis. Our network bandwidth should be sufficient, we are using
100 base T, which is far from saturated. We are using 1G port into the
file system,
On Thu, Jan 04, 2001 at 04:51:23PM -0600, Cheryl Tipple wrote:
It appears we have a performance problem within our CVS system.
[CPU, network bandwidth, filesystem access path, RAM, swap are
all far from saturated]
Can anyone tell me if there are any
[...] tests I can run to trace this
28 matches
Mail list logo
