Community
Participate
Working Groups
"Synchronize" is unacceptable long: it takes 105 seconds for my project. For comparison, I have tried CVS (v.1.11.15) command line: "cvs -z9 up -d -P" takes 14 seconds, "cvs -z9 status" takes 25 seconds. Enviroment: 20040428 integration build of Eclipse, linux 2.4.26. Of course, compression level is set to 9.
Just want to add, time is long for CVS module with few years history. For newly checked in module the action doesn't take long time - judging by "Progress" view. Andrew
We will investigate shortly. In the mean time, I would be curious to know what the time comparison is with no compression on your project (if you don't mind). The CVS client in Eclipse only compresses file contents so it is possible that the increase in time (at least in part) comes from the rest of the communications (which could make up a substantial part of the sync).
OK, new tests results are below. Synchronize, compression 9 - 102s cvs -z9 up -d -P - 12s cvs -z9 status - 17s Synchronize, compression 0 - 103s cvs -z0 up -d -P - 14s cvs -z0 status - 17s I'd want to add some comments: - I have dialup 33600 connection to our CVS server, - we have separated our project tree unders testing into two projects, so, numbers are smaller, - in spite of close numers for z0 and z9, network traffic graphs were different for CVS command line (for z9, of course, with much lower KB/s), - for Synchronize action traffic graphs were very similar for 0 and 9 compression options. The most time of graph takes fragment with approximately constant simultaneous ~2 KB/s output and ~1.5 KB/s input flows; before this long constant period there are short output and even shorter input fragments with ~10KB/s (I'm sure, PPP compression takes place here), - measurements were done for project with few years history, if you remember, for newly checked in project Synchronize action is rather quick, - all tests were done when all project files were in disk cache already. Andrew
One more thing. What connection method are you using (pserver, extssh)?
Could you also perform a Team>Update (not from the sync view) on your project and then try the synchronize again. I know this sounds like it shouldn't matter but we had to do some optimizations involving pruned folders which may be a culprit here.
Michael, I'm using pserver. Andrew
Michael, After updating (18s) Synchronize action was 12s (!). Then, I have restarted Eclipse and run Synchronize action (without updating). And it was the same (12s). So, update command seems to be a cure for the issue :-) I have never run Team -> update before. "Synchronize", "left arrow", "right arrow" buttons of Synchronize view clicking was the common scenario. Andrew
Great. The problem was that you checked out the project with an earlier build. Checking out in the latest builds will essentially leave the project in the same state as the Team>Update did so this problem should not be seen in the future (unless a project is checked out with the command line and imported into Eclipse).
I have imported existing shared project 22 of april (.metadata dir has this time stamp). I think, this was done with 20040420 integration build. Probably, some tuning must be done in creating/importing-new-shared-project code, if that wasn't done in one of the later builds. Thanks!
