[cvsnt] Force commit
Michael.Wojcik at microfocus.com
Thu Dec 14 15:30:35 GMT 2006
> 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
> 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.
Principal Software Systems Developer, Micro Focus
More information about the cvsnt