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

Closing edited files without saving problematic for readonly #21

Open
dpp-gerrit opened this issue Nov 21, 2011 · 3 comments
Open

Closing edited files without saving problematic for readonly #21

dpp-gerrit opened this issue Nov 21, 2011 · 3 comments
Labels
Aspect: Consistency Issue with Saros' consistency handling

Comments

@dpp-gerrit
Copy link

When the host closes a file after changing it, without saving, all other hosts have a dialog triggered asking if the file changes should be saved.

Selecting "yes" as a readonly users results in an inconsistency (watchdog barks).

There should be no dialog for session participants - the reset of the file changes needs to be propagated to all participants in a consistent way without requiring user interaction.

Reported by: netcorps

Original Ticket: dpp/bugs/645

@dpp-gerrit
Copy link
Author

This is a more generell problem. The Question is: "What do we do, if Alice closes a file that was also edited by Bob?"
If you think a little bit ahead it gets even worse...
Imagine a file "A.java" is opened by Alice, Bob an both can write to the file. What if Alice and Bob did made changes to "A.java" and Alice decides to close without saving? What do we do? If we want a convincing solution, we have to save all changes made by Bob and revert everything Alice made. This could be more complex if there are more than two programmers in the project.
On the other hand we have to think about how likely this scenario is. So, is this really a level 7 bug?

Original comment by: donut87

@dpp-gerrit
Copy link
Author

This happened in my heuristic evaluation, in my cognitive walkthrough and in the usability tests with participants in the company i work for.

So the frequency of occurences might be low, but the probability of it occuring is high. People type a comment to illustrate something while explaining in the code. Then close the file and not saving the temporary comment.

This should be fixed, but it is not a major problem, so i revied the priority.

Original comment by: netcorps

@dpp-gerrit
Copy link
Author

> Selecting "yes" as a readonly users results in an inconsistency (watchdog barks).

Hmm, normally every user that is not the host must get an inconsitency warning.

This is really hard to fix, yes it is annoying. You explained a special case, in normal operation you are seldom writing code and then just discard it.

Can somebody test this scenario ?

Client X writes code ... after a while he noticed that his approuch was wrong and discard its changes.

Question: Are those changes also discarded on the host side ?

If not, you have to resync the file via watchdog, delete the newly written code and press save.

Original comment by: kargor

@dpp-gerrit dpp-gerrit added Aspect: Consistency Issue with Saros' consistency handling sourceforge labels Mar 27, 2018
@dpp-gerrit dpp-gerrit self-assigned this Mar 27, 2018
@dpp-gerrit dpp-gerrit removed their assignment Mar 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Aspect: Consistency Issue with Saros' consistency handling
Projects
None yet
Development

No branches or pull requests

2 participants