Community
Participate
Working Groups
The general idea behind 'configure project to use watch/edit' is to ensure no conflicts ever occur unless specifically expected (by clicking through the 'file is already being edited' warning popup box). However, with the following scenario, a conflict WILL happen: 1. User A checks out/updates the project. 2. User B edits file X (and gets marked as editor). 3. User B commits file X (and gets unmarked as editor). 4. User A edits file X (eclipse checks for editors, finds none, automatically tags itself as editor, and happily lets user A edit file) 5. User A tries to commit file X but gets an out of date CVS error as the repository file is newer compared to what A started to work with in step #4. 6. User A now has to go through a tedious compare between his version and the latest repository version (especially annoying with some binary file as making a DIFF is not practical). Proposed solution: In addition to performing an 'editors' check, perform a 'latest version' check, and warn if the user attempts to edit an out-of-date file. Possibly offer this functionality separate from CVS WATCH/EDIT, as it's useful on its own even without watch/edit (though obviously these 2 separate features together are most useful as they should positively ensure no conflict will ever happen unless intentional). Regardless of specific setting, ALWAYS do an up-to-date check if a 'is being edited' check is being sent (as 'being edited' is useless without an up-to-date check). Current workaround: Always manually select Team/Update before you select Team/ Edit (or let eclipse automatically edit for you). Annoying and practically defeats the purpose of automatic edit.
Your proposal makes sense to me. However, there is no plan to address it unless a patch is provided.
I am submitting a patch to the cvs core and cvs ui projects that does an update check on the file when watch/edit is configured to send a notification synchronously. If the file is out of date it will be updated depending on the new ui prefs. A few sidenotes: Refactoring something that causes an update will cause the refactoring to fail. It bails out nicely though and you can just do the refactoring again as a workaround. I had to pull in the execute code from EclipseResource into Command so that I could run the update with a scheduling rule that was compatible with what was already being locked. If anyones has any ideas around these issues let me know.
Created attachment 23386 [details] cvs core project patch (3.1 RC2 sources)
Created attachment 23387 [details] cvs ui project patch (3.1 RC2 sources)
Thansk for the patch. We'll have a look once 3.1. is deleivered.
I've released the patch to HEAD with the following modifications: 1) Simplified the code to check for new revisions and update. 2) Change the default to Never Update since there is considerable overhead in both of the other options 3) Added code to ensure that the required scheduling rules are obtained.
Verified in I20050808-2000.
It's fixed and works great, but there still appears to be a couple of issues related to this: (1) If you choose not to update, then the file is locked for editing. You have to close the file and re-open it again to edit. (2) If you initiate the up-to-date check using Ctrl-X for Cut, then after updating, if characters were inserted or deleted before the current selection, then the wrong region is cut. It's probably better to update but cancel the cut operation in this situation. Additionally, I did anyone look at the issues Rob raised in Comment #2? I don't have perms to re-open the bug... Hopefully someone sees this comment.
I would prefer that we report any additional issues in separate bugs. Otherwise, it becomes to difficult to figure out what the remaining work for a bug is. The issue from comment 2 is a known issue so it may already have a bug report in JDT UI. The 2nd item in comment 8 is related to this but is the oposite (i.e. the Paste continues but probably should stop). You could log a bug report against Platform Text for this. The 1st item in comment 8 should be logged against Platform CVS.
Is it possible to provide the patch for R2.1 also? We also meet the same difficulty. Thanks.
