Community
Participate
Working Groups
Build 20030206 I think this bug has always been in, but when selecting a binary JAR for synchronization with server, it will retrieve the old JAR content only to tell me it has a different revision number. This makes posting patches on dev.eclipse.org remotely really painfull (should simply have committed without checking to workaround this bug).
Created attachment 3383 [details] Progress showing JAR retrieval when initiating synchronization
Unfortunately, this is how CVS works (i.e sends all modified local contents to the server on a sync/update). This is done so the server can determine if there really is a change and also to perform any auto-merging for text files. Given that the server will not auto-merge binary files, it may be possible to optimize this case without loss of functionality. In the case where there isn't really a change, the update would have reset the sync info so the file was no longer dirty. Since we now do this on commit, it should be OK.
When we post patch on JDT/Core page, we are hitting this issue over and over. The deadly case is if someone else posted a patch in the meantime. Commit no longer work, since a conflict is detected. The only way to release the patch is to synchronize, and thus download the entire remote file, which I will override with my local change.
We should fix try and fix for 2.1.1. There are other cases when too much file content is sent to the server: adding files and synchronizing binary files.
Created attachment 5418 [details] Fix for this bug
The attached patch prevents us from sending the contents of binary files when doing an UPDATE on synchronize. However, if you are using a slow link then you will probably want to make sure the "Window->Preferences->Team->CVS->Consider file contents in comparisons" option is turned OFF. If this option is left on, the binary file contents will be sent from the server as the data is required for this feature. (Without the patch and with this option on, the file data was actually being sent twice). I will open a separate bug report regarding this option. It is possible we want this feature to ignore binary files as well. Until then, just turn the option off. It is not clear it is strictly necessary anyhow since commit seems to do the right thing. The add file case Jean-Michel talked about seems to have been fixed at an earlier date by the addition of an AddFile Visitor. Also, the resetting of timestamp when commiting binary files that are the same but with different time stamps does work properly. IE nothing is really commited to the server.
See bug 39880 for discussion of "Consider file contents in comparisons" option
Released to HEAD
