[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Large file actual performance report; cvs use of ,v header issometim
RE: Large file actual performance report; cvs use of ,v header issometimes non-optimal.
Fri, 18 Jan 2008 09:51:40 +1100
There was a separate off newsgroup discussion which I wont go into here.
> CVS-NT not on distribution, no auto-security
> updates for 5 years.
As opposed to the 3 year old copy of CVS 1.11 (1.11.19) that your
auto-security updates have gotten you?
I think for anyone reading this newsgroup for some time that my thoughts
on replacing software for no-good-business-reason are well known. If
you don't need the features of CVS 1.12 or CVSNT 2.5.04 or PVCS or
ClearCase or any other tool then I am the last person that is going to
advocate that you should change.
However your post referred to specific problems that do not exist when
using the latest versions with best-practice and I wanted to make it
clear to other readers that there was no cause for alarm.
Your post also expressed what to me seems a complex and error prone way
of dealing with UTF16 files that obviously you are comfortable with but
others may be interested to know there are other ways / tools /
extensions that may suit them better.
Since your post did not actually contain a question and it appears as
though you've taken offence at me answering what I considered implied
questions it was probably more appropriate for you to post your test
results to gnu.cvs.bug
> Even though not big by your standards, the CVS
> server cannot handle a couple of small branches and less than
> 30 revisions without consuming hours and hours of server time.
For the benefit of others reading or finding this thread in future
searches: if you use the latest server and best practice this problem
does not occur.
- RE: Large file actual performance report; cvs use of ,v header issometimes non-optimal.,
Arthur Barrett <=