atom-local-history no longer works

[croaker000]

https://github.com/Nicolab/atom-local-history

Not sure when this happened (ie what Pulsar version broke it) but it's been dodgy for a while.

It's supposed to backup your file when you save it so you can roll back if you make a mistake. It's well explained on its GitHub entry.

I'm now no longer getting files backed up (across a linux nfs share, but that shouldn't be an issue, it's been fine previously). The context menu is missing and the "current project" command never loads a list of previous files.

NB: The current developer is looking for a new maintainer so this is a ripe time for someone (Pulsar team?) to take over and make it Pulsar compatible.

[savetheclocktower]

Do you notice any errors in the developer console when you perform saves or invoke any of its commands?

EDIT: Also curious whether changing the value of local-history.historyStoragePath appears to make any difference. That would narrow down where the problem could be.

[croaker000]

Sorry, forgot to mention that. No, there's no clues there unfortunately.

[savetheclocktower]

I'll probably install this package today and give it a shot.

[savetheclocktower]

So I installed it from source and did a ppm link --dev. Aside from its odd choice of how to derive its default storage directory (trying to traverse upward from __dirname instead of reading process.env.ATOM_HOME), it's not doing anything wrong; revisions are going into the directory of its choosing.

Can you try setting historyStoragePath to something on your local disk just to rule out NFS as a factor?

EDIT: I should really read more closely. The fact that the menu item isn't present is a strong indicator that something is going wrong during package loading, since those menu items are consumed at startup. Is there a “Local history” entry in the “Packages” menu? If you open the command palette and type local history, do you see anything?

[savetheclocktower]

I'm also curious about what has been “dodgy” about it in the past — the logic in the source code seems pretty straightforward.

[croaker000]

I'm editing PHP files if that's important? I can also confirm that my Pulsar projects are the files on the NFS share and that my historyStoragePath is ~/.pulsar/local-history on my local disk (so saving from NFS to local HD).
I'm trying to estimate the file dates but I think my whole atom-local-history plugin stopped working properly after my installing 1.114. It seems that before then, saves were intermittent. I gone back over various projects I've worked on over the last 2 months and files I know I've edited have not been backed up.
I still don't get a context menu option and the "current project" command hasn't worked for as long as I can remember using Pulsar - it's not the sort of thing I use often, only when I bugger something up, so remembering specifics over a long period is hard.

[savetheclocktower]

I edited an earlier comment instead of posting a new one, so I'll just ask again here:

The fact that the context menu item isn't present is a strong indicator that something is going wrong during package loading, since those menu items are consumed at startup. Is there a “Local history” entry in the “Packages” menu? If you open the command palette and type local history, do you see anything?

[croaker000]

Packages menu: Yes, the "Local history" sub-menu exists
Context menu: No, not there
Command Palette: Yes, the commands appear but selecting "current file" gives me a blank list (even though there should be candidates there)

[savetheclocktower]

That's an extremely strange list of symptoms.

Here are some things you could try:

• First, open developer tools to the console tab, then invoke the “Window: Reload” command. That'll show you all log messages starting from the very beginning of the window loading process. You'll see any logging (including errors) emitted by various packages as they get activated. It's possible there's an error happening during this package's activation.
• The nuclear option would be to quit Pulsar, back up your entire .pulsar directory (more than once if you're paranoid!), delete it (so that it gets re-created on next launch), then install only the local-history package and see how it behaves under those circumstances. After that experiment, you can quit Pulsar and restore your original .pulsar directory; everything will be back to normal on the next launch.
• If you have any level of comfort inside JavaScript — just comfort, not expertise — a different option would be to back up your .pulsar folder, then go into ~/.pulsar/packages/local-history and edit the source code of the package. Your changes would take effect upon window reload. You could insert some console.log statements in various places just to ascertain how far the package is getting into its activation and where things are going wrong.

If you go with the third option, here are some places you could insert logging:

• In lib/local-history.js, insert logging into the onWillSave callback on line 69. That's the function that gets called before Pulsar saves a file. Then maybe a logging statement just above this line so you can tell whether it's actually going to do the backup. You should also log at the bottom of the activate method just to ensure it's getting through activation correctly, then just above line 132 to see if an instance of LocalHistoryView is getting returned.
• In lib/local-history-view.js, the saveRevision function figures out what the file's name will be, then actually attempts to do the writing. You should log the value of file just after this line to find out what the backup file's path will be, then log just above this line to find out if err is present. If it is, then something has gone wrong with the save; if not, then all has gone according to plan. (I doubt it's getting this far based on your symptoms, but we'll see.)

I'm still flummoxed because most of the ways that I can envision this package failing would produce error messages in the console! But this package works perfectly for me in my limited testing, and I'm on 1.114, so there's a solution to this mystery somewhere. If I had to guess, I'd say that it's activating properly, but either (a) skipping the process of saving because it's misjudging file sizes, or (b) failing to write to the local directory but thinking it has succeeded. I bet I'm wrong, though!