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
Default keep revisions to disabled, and remove tests for revisions #653
Default keep revisions to disabled, and remove tests for revisions #653
Conversation
This commit sets the "keep revisions" setting to disabled by default for new projects. It also removes the test cases associated with revisions. The revisions feature as currently implemented is of questionable use. It has been a source of performance issues for users, and has consumed developer time in attempts to address its shortcomings. This commit is the first step to deprecate the current revisions feature.
Hopefully, this does not get permanently disabled. Turning it off by default will put others people work at risk. This feature has saved me from stupid mistakes a couple of times. |
@verbalshadow please describe how this feature helped you. The plan is to completely remove the revisions feature (as it is currently implemented) in a future Manuskript release. |
@gedakc I am watching this conversation with a lot of apprehension. The way Manuskript handles revisions (diff specifically) is very smart. You can totally decide to throw away the "automatic" part of it, since even Scrivener doesn't have automatic saving of revisions, but you can't just throw it all away. I made a feature request for Manual saving of revisions. That should be done in case you want to disable the automatic part of it. I would be more in favor of having both. By taking away automatic revisions you are also getting rid of something that differentiates this piece of software from all the rest. I've had zero problems with it on Windows 10 and have just put in my 135000 words Novel. The only performance issues I've had are with spell checker and with documents larger than 3000 words. |
@Eusorph please describe exactly how this feature helps you. |
@gedakc A form of either manual revisions (Scrivener), automatic (Manuskript) or both is necessary if a writer inputs his novel in a computer. Computers are supposedly smarter than paper, but then they aren't in this case, because on paper you are obliged each time you want to change something to rewrite it, thus keeping an older version that you can always see and go back to (unless you're a dumbass and like to throw away your own work). Why is it especially necessary on a computer? Well, any decent writer will always try to say what he/she wants to say in the best way possible, and that means trying out different versions of paragraphs or even full chapters. Often, in the process you get carried away and destroy what good you had done and NEED to go back to the previous version, adding only a few things that you found during the process. On a computer, since it applies destructive editing, it is impossible to do so unless you have some sort of a revision mode. |
My use case is simple. Manuskript doesn't have grammar or style correction integrated. I have to use other tools for this task. LibreOffice, Hemingway and beyond. I have accidentally deleted large/small portions of text and not noticed until later. Auto revisions allowed me to recover this lost text. |
@Eusorph I use Manuskript on Windows 10 myself, but when I had the revisions feature turned on the entire program would freeze every few seconds while I was in the middle of typing. There was absolutely nothing more frustrating to be typing, see nothing is appearing, be pulled out of it, and eventually see everything appear in a rush. Maybe it is due to the way it is being stored, maybe it is due to the revision feature, but for me personally the revision feature is the drop in the bucket that made me almost deem Manuskript as unfit for use. And since I started hanging out here, I have seen multiple crash reports and corrupted projects that can be directly traced back to the revision feature somehow screwing up and making the entire project unloadable. (In some cases it led to complete data loss, but that was because one bug triggered another, so I don't want to put the full blame on the revision feature for that one.) Perhaps these issues only appear on certain OSes, or maybe I am just a very lucky person, but right now, it seems to be akin to a game of Russian roulette where some people play endlessly without the bullet in the chamber, and others meet their end prematurely with a very loud bang. What we want to do is to improve Manuskript and obviously the feature itself, too. But right now, people use the feature in different ways. Some of them use them as dumb backups to 'go back in time'. Others do not use them at all because they have no use for them. And others would like to use the feature, but they want more granularity so they can see the differences between each version in a better way. And from what we had seen so far, the current implementation of the feature has more drawbacks than it has positives. And thus it needs to change. How? We are not quite sure yet as that is something that needs to be further investigated. But the nature of the issues and shortcomings compared to expectations makes it quite likely that such a change may not be backwards compatible. It may not be possible to squeeze the old revisions into the new system, whatever that is going to be. Tearing it out is not the intention: replacing it with something better, is. But given the amount of problems the feature has caused, it is plain stupid not to inform users, especially when we haven't done much more than apply the odd band-aid. TL;DR: Everyone wants it to be better, but 'better' is a flexible concept that needs further consideration and research. |
@worstje I understand, then, as I said, just switch to manual snapshots. You don't need to invent the wheel: that is the way Scrivener does it and covers a good deal. |
A project moves forward based on the work of it's contributors. Time and effort spent in one area takes away time from other areas. Because the revision feature has caused much grief and taken developers away from more important issues, we decided to disable this feature by default. |
This commit sets the "keep revisions" setting to disabled by default
for new projects. It also removes the test cases associated with
revisions.
The revisions feature as currently implemented is of questionable use.
It has been a source of performance issues for users, and has consumed
developer time in attempts to address its shortcomings. This commit
is the first step to deprecate the current revisions feature.