Community
Participate
Working Groups
CVS operations should not block all other types of operations. On slow links CVS operations can take eg. an hour or so. It is a blocking operation so eg. I can't be commiting changes in one project AND work on another one. This works fine if I open another Eclipse window so why not make it possible in one window? Interesting thing is, if I edit a file in Eclipse window where CVS operation is running, then open the file in another window, copy/paste changes to that window and save file 'changed' marker disappears in first window as well so it's not completely blocked. Beginners may not know about opening another window and be stuck with this problem.
In general CVS operations only lock the project that is being operated on. If you know of a particular scenario where this does not appear to be happening, please log a bug (or reopen this one) with the exact steps you took to produce the problem so we can try and reproduce it.
I noticed two new/different examples of blocking CVS behavior: Example 1: start CVS project checkout and try to open another project while first one is being checked out. What I get is 'Open Project (Waiting)' task instead of opened project. The two projects are unrelated directly (they both use a library project in the same workspace). Example 2: start CVS project checkout, edit and try to save a file in another project. A modal window blocking entire Eclipse interface pops up with all tasks waiting for CVS checkout to complete. This is what I described in comment #1 but now I don't know why but the solution I described above (open new window) doesn't work anymore -- it blocks just as in the same window. Eclipse 3.3M3 Linux/GTK
I forgot to add that bug as described comment #1 was filed against Eclipse running on Windows XP.
This is a restriction of the Resources plug-in. Creating projects requires the workspace lock.
Slightly different usecase: I noticed that when deleting a project in my workspace, if a checkout is in progress, the project deletion is entirely on hold. I assume this comes from the scheduling rule on workspace root there. Shouldn't the project deletion be allowed still to clear its content, and only take the root lock when about to discard the (empty) project folder ? This would allow to better parallelize the operation...
To clarify: I think the parent lock is needed each time you intend to add/delete a child. What I was trying to say is that for folder/project deletion, emptying the folder doesn't require a lock on the parent already. So basically it could lock on the folder (which wouldn't collide with other project checkout any longer), and it would only grab the parent lock when physically deleting the (empty) folder.
Philippe, I think you should open a separate bug for your case. The resources API doesn't lock the workspace root for project deletion, this must be coming from LTK or someone else calling delete.
I raised bug 239404 for the LTK issue. I debugged the example 2 from comment 2. In this case file save and cvs checkout use non-conflicting rules. However checkout blocks save snapshot operation which uses the workspace root rule. And save snapshot actually blocks file save. So we have cvs checkout (1) with the project rule save snaphot (2) with the workspace root rule, blocked by cvs checkout file save (3) with the file rule, non-conflicting with the cvs checkout rule I came to the situation when (1) is running, (2) is blocked by (1), (3) is blocked by (2). And actually all workspace operations are blocked by the save snapshot operation. Maybe we should pre-empt snapshot job in this case?
I think that Resources is more appropriate place for it.
*** Bug 233665 has been marked as a duplicate of this bug. ***
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.
