Summary: | CVS Checkouts require the workspace rule and hence block operations on other projects | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Max Gilead <max.gilead> |
Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | john.arthorne, markus.kell.r, martinae, philippe_mulet, rajkumar.bakhru, Szymon.Brandys, tomasz.zarna |
Version: | 3.3 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 128709 | ||
Bug Blocks: |
Description
Max Gilead
2006-09-29 03:46:00 EDT
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. |