Bug 505690 - Spurious popups when 'deleting' files with GIT
Summary: Spurious popups when 'deleting' files with GIT
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Core (show other bugs)
Version: 4.1.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2016-10-11 05:13 EDT by Ed Willink CLA
Modified: 2016-10-15 06: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 Ed Willink CLA 2016-10-11 05:13:34 EDT
If an ecore file and its aird are committed to GIT, then a checkout of an earlier state results in their deletion, unhelpful popups appear

(Bug 1: the popup does not support text copy)

Bug 2: the popup: "Close the representations file?" "The ...aird file has been externally deleted, should we remove it and lose changes?" is unhelpful. The aird file is not open, there are no changes to lose, just the normal change of state for the new GIT. This is all totally unnecessary since the normal GIT guard against dirty files should work for aird files just the same as java files.
Comment 1 Pierre-Charles David CLA 2016-10-11 09:01:53 EDT
Technically the "aird" file is opened (well, in the sense "loaded" at least), and there are non-standard configurations where such operations could cause changes to be lost; it would probably never happen outside of Sirius-based products which explicitly enabled these configurations.

But I agree the popup is at best poorly worded and probably unnecessary in the vast majority of cases, and we should try to be smarter in detecting when it's really needed or not.
Comment 2 Ed Willink CLA 2016-10-11 09:11:28 EDT
(In reply to Ed Willink from comment #0)
> (Bug 1: the popup does not support text copy)

See Bug 505709.

(In reply to Pierre-Charles David from comment #1)
> there are non-standard configurations where such operations
> could cause changes to be lost

Easy to say, but if you have non-standard configurations that require non-standard behavior, it may be appropriate to revisit the rationale of the non-standard configurations. Once you start fighting the standard Eclipse workflow, an ever increasing number of facilities start to malfunction.

It seems to me that if you have a, hopefully very lazy, automatic AIRD open, you should also have an automatic AIRD close so that the AIRD is closed when Eclipse expects normal functionality.
Comment 3 Ed Willink CLA 2016-10-15 06:03:43 EDT
(In reply to Ed Willink from comment #0)
> "The ...aird file has
> been externally deleted, should we remove it and lose changes?"

A very similar problem occurs if a GIT Rebase Interactive undermines the uninterrupted existence of a *.aird file.