Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Autosave enhancement

<< < (3/4) > >>

oBFusCATed:
Falco:
You can't compare AutoCAD or any similar user program to an IDE.
 In a IDE the files are saved before every compilation and this is one of the most common operations users execute in an IDE.
I think most of the users of C::B are working with saved files (sources) most of the time.
Also, most of C::B's users probably use some kind of VCS, so they have some sort of a backup already.

thomas:

--- Quote from: oBFusCATed on November 16, 2013, 03:13:24 pm ---I'm using autosave in save-to-original file mode and I think that the mode where the file is saved with another name is useless and should be removed.
The reason is that with my workflow - I don't want to restore the version from 5 minutes ago, I want the last version just before the crash.
--- End quote ---
That's kind of true, and not true. I had added several modes because different people have different working patterns.

Sometimes you are just editing things and do not intend to save them to disk. Or, you only want to have consistent snapshots (no half-edited stuff) saved. Except of course when there's a crash, then you can open the half-edited file, complete the edit, and save it proper.

Using the "save-to-original-name" overwrites the original file without asking (actually it does a write-to-temp-swap, but that's irrespective). You may have to restore the file from version control only because Code::Blocks overwrote it when you didn't want that to happen. Maybe acceptable to you, but other people will think differently.
On the other hand, using the save-to-savefile mode, in the very rare event of a crash, you have two file versions, the one you explicitly saved (that is, one that you decided was "authorative") and one that is half-edited. Plus, you have one extra copy, which doesn't hurt. Harddisks fail rarely, but they do. In case your harddisk has an unrecoverable sector just at that very moment (a coincidence like a lotto win, but still), you still have at least another copy that's a few minutes old.

thomas:

--- Quote from: Bat on November 16, 2013, 02:46:24 pm ---But in my usage for 2 years, I found some random crashes or "hangs" that lead to some losts. I'm convinced that some (and even all) are plugins related.
--- End quote ---
I'm convinced of that too, with a minimum set of plugins that I'm using (mostly because I don't need them) I never see any crashes. Code completion used to be the source of all crashes once upon a time, but this is fixed for a long time, I'm using CC for ages now and never see a problem.


--- Quote ---If poeple know which file should be restored it's ok.
Files poeple are mainly working on are obvious
A minor modification (comment one line) done one hour ago can easily not recover.

--- End quote ---
I think you have to open them side by side manually anyway, since it's not a trivial thing (nor a thing that I'd like a computer to do). But yes, I can somehow see what you're saying.


--- Quote ---Which one do you refer ? As far as I know, I add boolean for "workspace is load", I do that because there is only one workspace loaded at a time ?
--- End quote ---
I only scanned the code quickly, but what I saw was a bool variable called "lock" which was set and verified at various places, presumably protecting the process of saving/loading project files and such.
That's generally OK, but it doesn't look like it would work. The user can open or close or save projects and workspaces or files at any time, asynchronously to the autosave plugin's timer. Which means that the user could close a project in the workspace while you're loading or saving it, etc.
If something needs to be locked, it has to be done properly, not by setting a bool value. Otherwise you create a race condition.

That said, I personally don't deem project saving something that is really urgent for autosave at all. Changes are not that frequent and not that large.

Alpha:
If it is pure crash recovery that you are looking for, an option would be to have the plugin save/update a config file (listing all files that were auto-saved) in the AppData folder each time it auto-saves files.  When the Code::Blocks exits, have the plugin delete this config file.
Now, when the plugin is loaded (on startup), if the config file exists, Code::Blocks probably crashed, so you can prompt the user with options to use auto-saved versions of files (listed in the config file).

Jenna:

--- Quote from: Alpha on November 17, 2013, 02:16:01 am ---If it is pure crash recovery that you are looking for, an option would be to have the plugin save/update a config file (listing all files that were auto-saved) in the AppData folder each time it auto-saves files.  When the Code::Blocks exits, have the plugin delete this config file.
Now, when the plugin is loaded (on startup), if the config file exists, Code::Blocks probably crashed, so you can prompt the user with options to use auto-saved versions of files (listed in the config file).

--- End quote ---
This attempt will not work, if a project is on a network share and is used from different systems.
If we really need such a fle, it should be side-by -side with the projectfile, like the *.layout file in my opinion.

Navigation

[0] Message Index

[#] Next page

[*] Previous page