Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WorkspaceCommandStackImpl method isSaveNeeded should not return true when all commands have been undone and a save is done #29

Open
pcdavid opened this issue Sep 4, 2022 · 1 comment
Labels
bugzilla Issues migrated from the old Eclipse Bugzilla

Comments

@pcdavid
Copy link
Contributor

pcdavid commented Sep 4, 2022

  • πŸ†” Bugzilla ID: #545313
  • πŸ“˜ Project: Modeling / EMF Services / Transaction
  • πŸ—“ Created: 2019-03-12T18:48:47Z
  • ❓ Status: REOPENED /
@pcdavid pcdavid added the bugzilla Issues migrated from the old Eclipse Bugzilla label Sep 4, 2022
@pcdavid
Copy link
Contributor Author

pcdavid commented Sep 4, 2022

Comment #0 on Tue Mar 12 2019 19:48:47 GMT+0100 (Central European Standard Time):

When the command stack is empty (i.e. no commands ever executed) or flushed, the WorkspaceCommandStackImpl#isSaveNeeded will still return true, which surely is not correct.

Even worse, calling #saveIsDone first doesn't help.

The problem is probably due to savedContext being null, and remaining null even after the #saveIsDone call when there is no undo operation on the stack. Naturally, this is exactly the case when no commands were executed yet.

This behaviour seems intended but I do not understand why, as it looks just plain wrong to me.

Comment #1 on Tue Mar 12 2019 20:23:04 GMT+0100 (Central European Standard Time):

Nevermind, another component was executing commands between my breakpoints.

Comment #2 on Thu Mar 14 2019 15:06:16 GMT+0100 (Central European Standard Time):

It seems there might actually be a bug with this thing: after executing some commands and saving, if you undo all commands, then do #saveIsDone, the savedContext is not set to null, and #isSaveNeeded will be true, even though the save was done.

Comment #3 on Thu Mar 14 2019 16:49:57 GMT+0100 (Central European Standard Time):

This is part of the EMF Transaction framework.

Comment #4 on Mon Mar 18 2019 18:53:37 GMT+0100 (Central European Standard Time):

I wrote a fix and test case (attached) but Gerrit doesn't allow me to push it.

Comment #5 on Thu Mar 21 2019 08:41:36 GMT+0100 (Central European Standard Time):

Hi,

I'll try to have a look in april, but will not have time before that.

Dimo, what command did you try and what kind of errors did Gerrit throw at you? If you've not contributed Gerrit patches before, it requires some non-obvious steps: https://wiki.eclipse.org/Gerrit has all the details on how to set things up.

Comment #6 on Sat May 14 2022 15:51:24 GMT+0200 (Central European Summer Time):

Eclipse EMF Transaction is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-transaction.

If this issue is relevant to you and still present in the latest release:

* Create a new issue at https://github.com/eclipse/emf-transaction/issues/.
  * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  * In the GitHub description, start with a link to this bugzilla ticket
  * Optionally add new content to the description if it can helps towards resolution
* Update bugzilla ticket
  * Add to "See also" property (up right column) the link to the newly created GitHub issue
  * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  * Set status as CLOSED MOVED

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Transaction will be archived and made read-only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugzilla Issues migrated from the old Eclipse Bugzilla
Projects
None yet
Development

No branches or pull requests

1 participant