Community
Participate
Working Groups
While displaying 3 incoming files: <--foo.txt <--bar.txt <--xyz.txt 1) Right click on foo.txt and choose update. 2) Quickly right-click on bar.txt while the update is occurring in the background (Always use background preference enabled) 3) While the menu is displayed, foo.txt is removed from the tree. Treeitems are recycled, meaning the item for "bar.txt" now displays "xyz.txt". 4) With the context menu still displayed, choose update. Expected behavior: - bar.txt is updated Actual behavior: - xyz.txt is updated Non-deterministic behavior is unacceptable for something as critical as throwing away unreleased changes (Overide and update), or trying to commit only a subset of your outgoing changes so as not to release unfinished code.
What build are you using. I am not able to reproduce this using 3.2.1. Also, it may have been fixed in 3.3 M3 due to bug 161805. Regardless, I would like to find a reproducable test case so I can confirm. What type of project are the files in? Are they at the root or in a subfolder. Have you changed any of the Synchronize view settings?
Maybe it was related to that bug, or maybe what I'm seeing is that a treeitem is removed, and the selection moves to some other item which is getting reused, and then that reused treeitem's text is updated later. So, it looks like a different resource is selected because there is a brief time where the stale text is shown. In other words, you click on xyz.txt, the Tree's selection moves to bar.txt when the commit finishes (because a treeitem was disposed), and then after a short delay that item's text changes to xyz.txt, which is what was originally selected. So, there is an intermediate state where selection appears to be on "bar.txt", but I don't think the selection is ever wrong. Reducing severity.
OK, I just saw a scenario that sounded much more like the original description and less like the comment 2 symptoms. 1) I committed some stuff higher up in the tree. 2) I double clicked on "EMFGraphicalEditor.java", which opened it in the editor area. Looked at its changes, which were related to a renamed class. Then went back (to sync view) and committed (via context menu) that file with "renamed" comment. 3) Then I went to select the file "rename" itself (i.e., resource deleted, resource added with new name). So I selected both changes/files, selected commit, chose "rename" comment again, and pressed OK. Then I got an error message saying the selected resource could not be committed, or something like that. So, now I expected that 2) had succeeded, and 3) failed because the tree was refreshed during the action being invoked and my pressing OK. Instead, *TWO* commits occurred (the ones I was trying to commit in step 3), and the commit in step 2) never happened. So, my guess is that when I committed in step 2, the changes that were actually committed were based on the next item in the tree (which happened to be the folder containing the renamed file, which corresponds to two outgoing changes). To summarize: - I double clicked on a TreeItem and looked at the changes - I went back to that TreeItem and right clicked and chose commit - The actual commit was an entire folder (which was a sibling to the intended file) further down in the tree.
Created attachment 56057 [details] Screenshot showing the problem Here is the proof. The dialog is modal so there's no way I changed the tree's selection in the synchronize view. Yet, you can see that only a single file had been selected, but the commit dialog is showing an entire folder with 3 changes as about-to-be-committed. And, that single file is *STILL* selected even after the background commits finished. So even if shifting of the treeitems had occurred, it has finished now and the selection is *STILL* only on a single resource, not a folder. As a band-aid, would it be possible to avoid removing anything from the tree, and instead gray them once they are committed? Or, another band-aid would be to verify that the dialog is showing the same "selection" that is currently selected in the sync view.
Created attachment 56058 [details] Updated Screenshot
*** This bug has been marked as a duplicate of bug 166483 ***
Oops, thought I was searching. Just one of those days...
I've been investigating this and conceptually, it shouldn't happen since the refresh of the tree happens in the UI thread. his means that the tree should be entirely updated and the new selection event fired before the user could click. I seem to recall an issue with someone running the event loop in a label provider. I wonder if that could be a cause of this as well (i.e., the label hasn't been updated yet so the selection is actually another item). Boris, do you think this is possible?
Michael, I am not sure if it is related, but when I run commit or create patch from the change set node in Synchronize view (3.3M4, with models) it pick the wrong set of resources (i.e. other change sets are picked up too). Same feature is working correctly if I select project within that change set.
(In reply to comment #9) > Michael, I am not sure if it is related, but when I run commit or create patch > from the change set node in Synchronize view (3.3M4, with models) it pick the > wrong set of resources (i.e. other change sets are picked up too). Same feature > is working correctly if I select project within that change set. I think this is because change sets can overlap. For example, change set A modifies file X, and change set B also modified file X. Not sure I understand changesets for patches though, I only use them when catching up.
(In reply to comment #10) > I think this is because change sets can overlap. For example, change set A > modifies file X, and change set B also modified file X. Not sure I understand > changesets for patches though, I only use them when catching up. In my case they wasn't overlapped. But even then if outgoing change set is selected, only resources from that particular change set should be included into commit or create patch action. This is quite critical for change sets that managed automatically, e.g. ones created by Mylar.
Eugene, the issue you mentioned sounds different. From your description, it sounds like you selected a change set and got additional resources included. This bug is about selecting a single file but getting a package and not the original file. An important aspect of this bug is also the fact that the selection is done during a commit (or update) when the tree is being changed. Unless your steps to reproduce match that description, I would ask you to create a separate bug report.
To summarize, there are two problems mentioned in this bug: 1) When updated, there is a gap between when the view gets updated and when the label is provided. Due to the algorithm used by the view to update the children of an item, this leads to an item having the wrong label. This is clearly a bug in the tree viewer and, given that I have not seen this recently, I believe it was fixed by bug 161805. 2) When committing, the selection in the view does not match what appears in the Commit Wizard. Again, I have not been able to reproduce this but I have modified the commit action to extract the selection from the selection provider before running. This will fix the problem if the bug is in the CommitAction but will not if the bug is in the view itself. Randy, I would be curious to know what plug-ins you have loaded when you see the problem. It is possible that the existence of other plug-ins is somehow contributing to this problem. It would also be helpful if you could try the latest 3.2.2 candidate builds to see if the problem is still occuring.
If the selections differ, rather than arbitrarily breaking the tie with what is currently in the selection provider (which might not reflect the user's intentions), you should fail and force the user to re-invoke the action. In my opinion, you should prevent commit, update, etc. entirely if there is a pending operation or the tree has not finished refreshing. You could still allow the user to look at changes, but not act on them. This also makes more sense when you consider failures that get reported asynchronously. If there are several pending operations, it is hard to understand what the failure message refers to. I'll try updating to 3.2.2 to see if it helps any.
I've seen this now. It happened when I selected several files individually while a synchronize was happening. When I right-clicked to open the context menu, there was some strange behavior (I think the view scrolled a bit). I right-clicked again after ensuring the visible selection was correct and committed. The proper files got committed but the message of a mismatch was logged. I agree that it is safer to fail in this case.
Code now changed to throw an exception.
