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.
> From: Arthur Barrett [mailto:arthur.barrett at march-hare.com] > Sent: Wednesday, 13 December, 2006 16:59 > > > Latency, on the other hand, makes actions such as diffing > > a lot of files take much longer > > Are you sure it's connection latency and not DNS or even > process start times on the server. Windows and Mac OS X have > particularly high overheads for process creation. I didn't say it was *connection* latency - I said it was communications channel latency. Latency issues apply throughout the conversation when the protocol performs request/response exchanges. And yes, I'm sure the primary delays are comms latency, aside from exceptional cases where bandwidth is a factor. I use the server often enough that the name stays cached most of the time, and even when it isn't, the DNS response (measured with batch-mode nslookup) is almost instantaneous. Nor is it likely to be a process startup issue; I have another CVSNT server running on one of my machines here for some files I version locally, and things are snappy running against it. > Are you talking about "cvs diff -c module" (which only needs > to resolve the DNS once and start one server process) or > using something like TortoiseCVS to get the entire file twice > and compare with WinMerge? What are the actual commands and workflow? I rarely use any GUI client, and I've never used Tortoise. I'm talking about workflows like recursive diffs - just a straightforward "cvs diff -c" or the like from a directory with a number of subdirectories. > Again - I suggest tackling the performance first, but if you > really are stuck 2.5.04 has those features to help. I'm not; as I noted in my previous message, the latency delays aren't enough to justify my spending time remediating them. In any case, my point wasn't performance issues with CVSNT. CVSNT is doing the job for me just fine (now that we finally upgraded our server and fixed the false-collision bug in the lockserver). I have to wait for CVSNT occasionally, but it still performs much better than PVCS VM-INET, which is what we were using before. (And it has scores of other advantages over PVCS, and crucially doesn't disrupt my workflow, thanks to its command-line origins.) I've built a few distributed versioning systems myself, and I think CVSNT is quite good. My point was that increasing bandwidth does not necessarily have any effect on latency. -- Michael Wojcik Principal Software Systems Developer, Micro Focus