Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Tue, 13 Jun 2006 18:03:13 -0400, John Hardin <jhardin at epicor.com> wrote: >Bo Berglund sez: > >> On Tue, 13 Jun 2006 14:29:28 -0400, John Hardin <jhardin at epicor.com> >> wrote: >> >> >Operations (commit, update, diff) involving large individual files >> >(larger than about 800KB) experience >> >> This is not a particularly large file... >> If you had said 800 Mb I would have agreed tit is s large file, but >> 800 kb is nothing, really. > >Wow. You regularly deal with 800kB+ text files? We have SQL database definition files that are text files and are 700-800 kb in size and they have 100-300 revisions each checked in by now. We do not see any problems like what you describe, but we use CVSNT build 2260 both on the server (a Windows 2000 Server dedicated PC) and on our workstations (Win XP-Pro SP2). > >> The problem is not connected with the file size for this size anyway. > >That's the only indicator I have. The problem becomes noticeable at around >800kB and gets unbearable at over 1.5MB, and non-cvsNT clients are not >seeing the delays. See my other post with trace and timing data (which is in >the moderator queue at the moment). Sounds bad. Does the server reside on the same network segment and what kind of machine is it in relation to the general domain setup? Also, what happens if you try to commit from the command line rather than from Tortoise? If you don't know how: cd <sandbox directory> <cvs install path>\cvs commit -m "your commit message here" file If this also results in "excessive delays" then you have ruled out Tortoise from the problem area. > >> (Or if the file is a binary file > >Nope. XML Text. We have those as well, no problems usually. >> and you have already stored many >> revisions, then the RCS file in the repository may be very large and >> this will make CVSNT run into performance issues like disk swapping etc >> depending on available RAM... > >We don't use cvsNT on the server side. Were you assuming I was talking about >server delays? Of course. Delays are in my world *always* caused by the client/server communication or by the server processing. The client just sends the files to the server for processing and receives back data to update the local sandbox with. It does not do a whole lot itself... HTH /Bo (Bo Berglund, developer in Sweden)