Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 87202

Summary:

(PatchAttached)[Watch/Edit] automatic 'editors' check doesn't check for updated versions.

Product:

[Eclipse Project] Platform

Reporter:

Reinier Zwitserloot <rz_eclipse.org>

Component:

CVS

Assignee:

platform-cvs-inbox <platform-cvs-inbox>

Status:

VERIFIED FIXED

QA Contact:

Severity:

enhancement

Priority:

CC:

luke.hutch

Version:

3.0.1

Keywords:

helpwanted

Target Milestone:

3.2 M1

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
cvs core project patch (3.1 RC2 sources)	none
cvs ui project patch (3.1 RC2 sources)	none

Description Reinier Zwitserloot

2005-03-04 23:26:19 EST

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.

Comment 1 Michael Valenta

2005-03-07 11:20:39 EST

Your proposal makes sense to me. However, there is no plan to address it 
unless a patch is provided.

Comment 2 Rob Hughes

2005-06-16 17:09:56 EDT

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.

Comment 3 Rob Hughes

2005-06-16 17:10:30 EDT

Created attachment 23386 [details]
cvs core project patch (3.1 RC2 sources)

Comment 4 Rob Hughes

2005-06-16 17:11:01 EDT

Created attachment 23387 [details]
cvs ui project patch (3.1 RC2 sources)

Comment 5 Michael Valenta

2005-06-17 09:20:28 EDT

Thansk for the patch. We'll have a look once 3.1. is deleivered.

Comment 6 Michael Valenta

2005-07-05 10:05:53 EDT

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.

Comment 7 Bogdan Gheorghe

2005-08-09 13:10:10 EDT

Verified in I20050808-2000.

Comment 8 Luke Hutchison

2005-08-10 00:06:02 EDT

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.

Comment 9 Michael Valenta

2005-08-10 08:27:18 EDT

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.

Comment 10 Jeremy Li

2005-08-22 22:17:39 EDT

Is it possible to provide the patch for R2.1 also? We also meet the same 
difficulty. Thanks.