Bug 68134 - [TeamOperations] saving of dirty editors may still make sense for some operations
Summary: [TeamOperations] saving of dirty editors may still make sense for some operat...
Status: ASSIGNED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: CVS (show other bugs)
Version: 3.0   Edit
Hardware: PC Windows XP
: P5 normal (vote)
Target Milestone: ---   Edit
Assignee: platform-cvs-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
: 106867 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-06-21 23:01 EDT by Jean-Michel Lemieux CLA
Modified: 2019-09-06 16:03 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Michel Lemieux CLA 2004-06-21 23:01:40 EDT
3.0 RC3
When committing changes to the server it makes sense to prompt the user about
un-saved editors, and not only the editors for the files being committed. I
missed a file because it was in an un-saved editor.

We should investigate extending TeamOperations to support prompt for all dirty
in addition to only for a specified file selection.
Comment 1 Michael Valenta CLA 2005-08-15 14:49:42 EDT
*** Bug 106867 has been marked as a duplicate of this bug. ***
Comment 2 Eugene Kuleshov CLA 2005-08-15 15:21:41 EDT
I'd like to suggest to show these unsaved editors as outgoing changes in
Syncronize view and if user choose to commit any of them Eclipse should suggest
to save modified files and then do actual commit.
Comment 3 Michael Valenta CLA 2005-08-15 15:27:25 EDT
Although that sounds interesting, I think that the effort to implement it 
would far exceed the benefit. I think a much more cost-effective (and platform 
consistent) approach would be to prompt for any open editors when committing 
and not just those in the current selection.
Comment 4 Eugene Kuleshov CLA 2005-08-15 15:33:21 EDT
(In reply to comment #3)
> Although that sounds interesting, I think that the effort to implement it 
> would far exceed the benefit. I think a much more cost-effective (and platform 
> consistent) approach would be to prompt for any open editors when committing 
> and not just those in the current selection.

Please at least show list of dirty dirty editors in that prompt dialog (with
check boxes) and by default preselect editors that overlap with current
synchronization set? Buttons select all, unselect all would be also nice, but it
is probably already part of some standard dialog.
Comment 5 Michael Valenta CLA 2005-08-15 15:43:13 EDT
Yes, this is the platform consistent means I was referring to. The plan is to 
show this dialog if there are any open editors during a commit.
Comment 6 Eugene Kuleshov CLA 2005-08-15 16:15:41 EDT
(In reply to comment #5)
> Yes, this is the platform consistent means I was referring to. The plan is to 
> show this dialog if there are any open editors during a commit.

So, will it show list of all unsaved editors but select only those that match
current commit/update scope?
Comment 7 Michael Valenta CLA 2005-08-15 16:55:58 EDT
It would have to show them all since the scope may have been determined by 
what was in the sync view and that would miss any open editors on files that 
have never been modified on disk but are modified in an editor.
Comment 8 Eugene Kuleshov CLA 2005-08-15 21:15:47 EDT
(In reply to comment #7)
> It would have to show them all since the scope may have been determined by 
> what was in the sync view and that would miss any open editors on files that 
> have never been modified on disk but are modified in an editor.

Heh. It sooo makes sense to show dirty editors in synchronize view. :-(

Comment 9 Michael Valenta CLA 2006-04-12 08:48:39 EDT
The model-based sync view prompts for any open editors in the same project when committing. I haven;t changed the Team>Commit behavior and we won't have time to do so in 3.2.
Comment 10 Michael Valenta CLA 2006-09-14 10:23:01 EDT
We do not plan on adressing this issue in 3.3.
Comment 11 Eclipse Webmaster CLA 2019-09-06 16:03:44 EDT
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.