Bugzilla – Full Text Bug Listing
| Summary: | [Sync View] Should automatically refresh before synchronising | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alain ésilets <alain.desilets> |
| Component: | CVS | Assignee: | platform-cvs-inbox <platform-cvs-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P4 | CC: | avital.oliver, chrislong, ekuleshov, infomail, jamesblackburn+eclipse, noel, oyvind.harboe, preston, rnorton |
| Version: | 3.0 | Keywords: | helpwanted |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
|
Description
Alain ésilets
Enable the following preference: Preferences > Workbench > Refresh Workspace Automatically. *** Bug 101915 has been marked as a duplicate of this bug. *** *** Bug 106919 has been marked as a duplicate of this bug. *** *** Bug 112296 has been marked as a duplicate of this bug. *** Removing "Refresh" would help make CVS/Team functionality more accessible to a wider audience, i.e. non-technical personell would find the Team functionality less intimidating. *** Bug 128597 has been marked as a duplicate of this bug. *** *** Bug 151949 has been marked as a duplicate of this bug. *** First, this bug is marked as "PC/Windows XP" when the problem is generic. Note that as written this bug specifies a solution (sync view in Eclipse before CVS operation), when the solution should be left up to the implementor. The underlying problem is that CVS operations (and perhaps other "Team" operations) may fail if changes to the filesystem occur outside Eclipse. The current manual work-around is to perform a "Refresh". The current suggested configuration work-around is to enable the option under Preferences | General | Workspace | "Refresh automatically". Neither is optimal. I am assuming that the manual "Refresh" operation on a project in Eclipse visits the directory enties for all files within the project. I am also assuming that for some large projects the "Refresh" operation is expensive (especially when files are remote). The current implementation does not perform a "Refresh" before "Team" operations. This is optimal and correct *most* of the time (when changes are made from within Eclipse). On Windows we can use file-change notifications to detect when changes are made outside of Eclipse. This is optimal and will catch *most* changes (not all!) - but only on Windows. This is a very worthwhile optimization given the majority of Eclipse users are likely on Windows desktops. Unfortunately the file-change notifications are *not* currently looked for by default. On non-Windows platforms (and on Windows when file-change notifications fail) performing a full-tree refresh is a non-optimal waste of time, in *most* cases. This is a case where being lazy is optimal. :) Better to omit the full-refresh operation until needed. The CVS client in Eclipse currently detects when a refresh is needed. When the CVS client complains - then and only then force an automatic refresh. The problem is that the CVS operations in Eclipse are built on top of the Workspace resources and make use of the cached file information (for improved performance). Because of this, a CVS operation may miss externally modified files (i.e. the operation would not detect that a refresh is needed). Here is a restatement of what you said with some additional comments. 1) On windows, the file system can notify clients of file system changes. The Eclipse "refresh automatically" preference makes use of this facility already. Therefore, on Windows, your best bet is to enable the preference. 2) On Linux and other platforms, we need to poll for changes. One way to do this is the run a job every so often that looks for changes which is what the "refresh automatically" preference does on these platforms. Another is for the user (or the CVS operation) to explicitly perform a refresh. In the former case, it is possible that changes get missed. The later has a perfomance overhead but will ensure that external changes are not missed. Given the above, it looks to me that the best solution is to provide a preference to perform a refresh before certain CVS operations (e.g. synchronize, update, and commit). On windows, you probably wouldn't need to use it since the "refresh automatically" uses the windows API to be notified of changes but you may want to use it on other platforms where the automatic refresh uses polling. Thanks for the clarification - in particular where I was reduced to guessing about Eclipse implementation. :) At the risk of repeating - on Windows the file-change notification is a best-effort service. For local files the file-change notification is very reliable. For remote files, it might work. http://support.microsoft.com/kb/q188321/ http://support.microsoft.com/kb/271148/EN-US/ (also local changes on Samba servers) Since the filesystem changes other than through Eclipse are more unusual than usual, performing a refresh every time is not optimal. Could skip the unconditional refresh. Could delay performing a refresh until the need is indicated by the CVS client. Seems like this breaks down into the following cases - in order of probability. 1. Local files on Windows : Optimal default would be to use file-change notifications so "Refresh" is never needed. 2. Local files on non-Windows : Optimal default would be to perform "Refresh" before CVS operations (walking the local filesystem is cheap). 3. Remote files on any platform : Optimal default would be to perform "Refresh" only if the CVS operation fails (due to stale info). (And again this is not PC/Windows XP specific.) The biggest impact of this bug is that newcomers to Eclipse(or indeed developers in general that loathe version control, yes, they do exist) keep stumbling over minor issues with CVS/Team in Eclipse. With this in mind, I would like no configuration options, nothing to read up on, no user enforced rules, it should just work. - If automatic refresh works without negative side effects, then it should be made default and the Refresh button should be removed(at least when automatic refresh is enabled). Note that novice users can have a large number of files in their projects. Automatic Refresh with a Refresh button does not inspire to great confidence in that feature. - If automatic refresh is off, then a forced Refresh(or it's equivalent thereof implementation wise) should happen before a Team synchronize. *** Bug 165158 has been marked as a duplicate of this bug. *** This bug can result in corruption of working tree (i.e. data loss) as described in above bug. To add to prior comments ... Behaviors (1) or (2) should be ENABLED by default (rather than disabled) as this is simply the right thing to do the vast majority of the time. I believe all this requires is a change in the default value of an option. Behavior (3) is likely to require new code, may be tricky, but is optimal for remote/large sets of resources. The idea is to: a) Run the CVS operation (or other "Team" implementation?). b) If the CVS client reports "out of sync" then force (2), a full tree refresh. c) Re-run the CVS operation (once). (And again this is *NOT* PC/Windows XP specific.) Other commenters seem to be mentioning a warning about the file system being out of sync. I never receive such a warning using Eclipse 3.2.0 and got a corrupted checkout as a result. Is this then a separate bug? The warning happens in some situations and not others (e.g. if the file had an outgoing change and then was modified externally, you would get a warning but if the file was clean when it was modified externally, you wouldn't). OK. In fact all my edits are happening within Eclipse -- it is just the commit which was done on the command line. Is it possible to detect if the CVS/Entries file has been modified outside of Eclipse and issue the same warning in this case? It would be possible but, in the end, you would end up doing just as much work as a refresh (i.e. you would need to compare the cached timestamp with the on-disk timestamp for every file. This bug happened to me several times, but in my case refresh does *not* solve the issue. I tried reproducing the bug and succeeded. This is the scenario: I create a new CVS module with one file (0.mp3). If I change 0.mp3 from an external editor (a text editor), and then refresh in eclipse, it notices the change. But, if I run a different program (in this case id3remover [http://sourceforge.net/projects/id3remover/]), it does *not* notice the change, although the file size has changed. When I tried to research it better, I noticed that id3remover does *not* change the date of the file. Is there a solution for this scenario? It seems odd that the timestamp is not changed when the file contents have changed. You may want to contact the providers of the software in question to see if this is intended behavior. That is true, and I can never be sure that other programs won't have the same behavior. Could there be a way of doing some sort of 'hard refresh' which compares some type of hash for each file? What would happen if I used the command prompt and did a 'cvs commit'? Would it recognize the changed files? What you propose would have a cost that is not trivial. I think it is reasonable to assume that, if the contents of a file are changed that clients can expect the timestamp to change. Conversely, it is reasonable to expect that there will be problems if the contents of a file are changed and the timestamp is not changed. It is reasonable to assume that, but in my case I have modified files which I *cannot* commit. My only solution would be to touch them and then commit them, but I would like to avoid future situations similar to this one, instead of just finding a 'patch' solution here. If your assessment is correct, the proper solution would be to get a fixed version of the software that is at fault. I think it is unreasonable to expect that every piece of software that depends on the timestamp to indicate that the contents of a file has changed should be modified to compensate for such a bug. If you can't get an updated version of the software, then your stated work around sounds reasonable to me. I must admit that I am surprised that the software in question would modify the file contents with out changing the modification timestamp given that they would explicitly need to write the code to prevent the timestamp from changing (i.e. the file system write will automatially change the timestamp). Seriously, I would contact the providers of the software or post on one of their forums to see why this is occurring. First, this issue is (still!) marked PC/Windows-specific for "OS". This is wrong. The issue applies to all platforms. Second, I am not sure what the change in priority means, but "least important" does not seem right. Eclipse does the wrong thing in this instance. It is easy to forget just how confusing this behavior can be for someone not familiar with the underlying implementation. Fair enough. I can increase the priority. However, we just don't have enough manpower to address this issue. Contributions are appreciated. I'd just like to say that I find this is the single most annoying problem with the Eclipse Team->CVS support today. Especially as it seems like, over time, more changes are happening to files behind Eclipse back as more and more projects are undertaken under the Eclipse umbrella. It is especially annoying when teaching people to use Eclipse & CVS who have never set their foot in a source control system and who are looking for *any* excuse to sabotage adoption of source control :-) This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |