[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problems with update -C
From: |
Derek Price |
Subject: |
Re: Problems with update -C |
Date: |
Fri, 09 Sep 2005 17:35:49 -0400 |
User-agent: |
Mozilla Thunderbird 1.0.6 (Windows/20050716) |
Mark E. Hamilton wrote:
> Is it intentional that 'cvs update' and 'cvs update -C' behave
> differently in this case? Assuming that the only difference is that
> the file has been touched, 'update' reports nothing about the file and
> 'update -C' tries to update it. I had expected that they would work
> the same way, ie, only refresh the files from the repository if it was
> actualy changed.
Well, "only refresh the files from the repository if it was actually
changed" means that the client sent the whole file to the server, it was
diffed against the desired version, and, if changes were found, then the
server sent the revised version back to the client.
The client normally saves bandwidth by only sending the files with
changed timestamps to the server, but update -C actually saves bandwidth
(probably) by skipping the send-the-file-to-the-server step.
update:
client ---> whole file ---> server
client <--- patch file <--- server
update -C:
client ---> file name ---> server
client <--- whole file <--- server
The return of the patch file is actually skipped in the second case.
Sending checksums to the server to check for differences before sending
the whole file has been suggested in the past, but I've never seen a
patch. With something like that in place, checking the checksum on
update -C before getting the file from the server could get the savings
you are looking for.
Regards,
Derek
--
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>