Bugzilla – Full Text Bug Listing
| Summary: | The timeout concept does not scale | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Oyvind Harboe <oyvind.harboe> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Oyvind Harboe
The timeout is needed for many situations. As an example, consider the case where a user has several projects in their workspace mapped to different repositories. If one of the repositories is not responding, the operation (e.g. synchronize) would time out on that repository and continue with the others. If there was no timeout, the user would be forced to cancel the entire operation and then figure out the subset of projects for which the operation would succeed. Can I appeal the decision to close this issue? The current situation is not good. Eclipse fails when everything is in fact working correctly. There is also no correct timeout value. This problem does not exist with the command line versions of CVS and I don't accept the example case give in #1 as an example where the timeout option is indispensible. Øyvind What would it accomplish if we left this open. The solution you proposed is unacceptable since it depends on the user aborting the operation. If the user didn't know that there was a blocked background operation (e.g. QuickDiff), it would be blocked indefinitely. Also, the case that I mentioned happens all the time to me so I don't know what you mean when you say it is invalid. I suppose that it would be possible to prompt the user when a timeout occurs to ask if they want to continue waiting (or if they want to increase the timeout value). However, this is not an easy fix and I do not have time to address it. Are you willing to implement, test and support this? If not, there is no point in leaving this bug open. >What would it accomplish if we left this open. The solution you proposed is >unacceptable since it depends on the user aborting the operation. If the user >didn't know that there was a blocked background operation (e.g. QuickDiff), it >would be blocked indefinitely. Also, the case that I mentioned happens all the >time to me so I don't know what you mean when you say it is invalid. > >I suppose that it would be possible to prompt the user when a timeout occurs >to ask if they want to continue waiting (or if they want to increase the >timeout value). However, this is not an easy fix and I do not have time to >address it. Are you willing to implement, test and support this? If not, there >is no point in leaving this bug open. If we can agree that the timeout concept does not scale well, then I think we've accomplished what we can hope to accomplish with this PR. AFAIK, it is a stated goal of the CVS support and Eclipse generally to scale more smoothly. Both todays implementation and the one that I tossed up in the air have unacceptable issues. I believe a permanent fix to this problem would minimally entail: - no modal dialog boxes - no options - the user eventually aborting the operation - the user being able to easily tell precisely which operation that he aborted - a long running operation should not unecessarily hold up other shorter operations Øyvind Actually, I don't see the link between having a timeout and scalability. It is more an issue of robustness. More specifically, how robust the CVS plugin is in the face of poor network communications. My feeling is that under normal working conditions, a 1 minute timeout is sufficient. For those cases where it is not, the timeout can be increased. One could argue that the link between the timeout occuring and the solution (increasing the timeout) is too weak and that a better link is needed (hence the solution I proposed). One could also claim that a 1 minute default is not long enough and that the default timeout should be increased. However, to require the user to manually cancel any operation that is not reponding is unacceptable. >Actually, I don't see the link between having a timeout and scalability. Try committing 20-30k files against a server on the LAN. There is plenty of activity all the time, yet it times out. Is this the intended and expected behaviour? Shouldn't there be some mechanism that resets the timeout whenever there is evidence of activity on the line? >However, to require the user to manually cancel any operation that is not >reponding is unacceptable. I remain unconvinced. How come the CVS command line handle these cases without trouble? Øyvind The CVS command line only has to deal with one operation to a single repository at a time. In that case, it is acceptable for the user the perform a CTRL-C if the connection hangs. Do you still have problems after increasing your timeout value? >The CVS command line only has to deal with one operation to a single >repository at a time. In that case, it is acceptable for the user the perform >a CTRL-C if the connection hangs. I thought the progress view was intended to support the concept of multiple parallel activities? >Do you still have problems after increasing your timeout value? In one particular case, yes. I've got another case where we plain gave up on committing to CVS using Eclipse. Roughly 50,000 files at 200k-1mbyte each. Øyvind So in one case, you no longer have a problem and in another you don't know if removing the timeout will even help you. Is that correct? I'm not saying there aren't issues here that need to be addressed. I just think that removing the timeout does not address the issues and, even if it did, would cause a whole bunch more issues. And, yes the progress view is designed to give the user some feedback on what is going on. However, it is not ubiquitous (i.e. it is only used for background jobs and not all CVS operations are performed in the background). Regardless of that, I just don't think the user wants to be bothered with knowing when they have to kill a background job that is blocked. You may understand when to do this but I assure you that the average user does not. >So in one case, you no longer have a problem Kinda. It is very tedious to repeat tests with CVS. I don't need to commit the exact same changes to the exact same files again. I don't know if things are still broken with a slightly increased number of files or slightly larger files. > and in another you don't know if removing the timeout will even help you. There is no such thing as a repeatable experiment. I have a working theory that the timeout problems are related to the large number of files. Are we satisified that the timeout issue is related to a large number of files, or is that an assumption that we should back up with more evidence? >I'm not saying there aren't issues here that need to be addressed. I just >think that removing the timeout does not address the issues and, even if it >did, would cause a whole bunch more issues. I agree that removing the timeout can cause other problems, but I don't see how removing the timeout option wouldn't fix the particular issues I'm seing with large commits/CVS operations. >And, yes the progress view is designed to give the user some feedback on what >is going on. However, it is not ubiquitous (i.e. it is only used for >background jobs and not all CVS operations are performed in the background). Is this by design, or just because the work isn't done yet? >Regardless of that, I just don't think the user wants to be bothered with >knowing when they have to kill a background job that is blocked. From a usability point of view, I remain unconvinced that timeout options are preferable to progress messages and aborting operations. >You may understand when to do this but I assure you that the average user does >not. Although aborting operations might be difficult to understand for these users, changing options is completely unfathomable to them. The Eclipse CVS GUI is the best in the industry AFAIK. I'm seing Eclipse CVS GUI & CVS deployed as a document control system amongst non-developers, all they use is the CVS GUI. This is where I've seen most of the >10,000 files projects. Not unfrequently the files are in the tens of megabytes. Eclipse does not seem to have an issue with file-sizes & CVS. Øyvind It sounds like we have agreed that: 1) removing the timeout will cause problems 2) there needs to be a stronger link between a timeout and the preference to change it. Basically, this is what I have been saying all along (Please read the second paragraph in comment 3). If you have some ideas on how to provide a stronger link between the timeout error and the timeout preference, I would be happy to listen. However, I will not consider removing the CVS timeout so there is no point in discussing it further. Regarding doing the actual work: I have made various changes to Eclipse CDT. Some patches have been accepted, others have not. What I have found is that there is little point in doing the work until there is a consensus w.r.t. what the solution should be. >I suppose that it would be possible to prompt the user when a timeout occurs >to ask if they want to continue waiting (or if they want to increase the >timeout value). All told, I think this would be a good solution. NB! I think it is necessary not to pause the CVS operation while the requester is displayed. Example of use as I imagine it: - start a commit(or other long-running CVS operations) - go home for the day - during the night Eclipse would put up a requester asking this question *without pausing the commit*. - once the Eclipse sees evidence of further activity on the line, what would happen to the requester? Presumably such false positives for timeouts could happen multiple times during a CVS operation. - the next morning with everything committed >It sounds like we have agreed that: > >1) removing the timeout will cause problems I remain somewhat unconvinced that it isn't possible to solve these problems, but I don't know enough about Eclipse CVS source code. Besides, it won't happen as you say. Reopening *** This bug has been marked as a duplicate of 85317 *** |