Hacker Read top | best | new | newcomments | leaders | about | bookmarklet login

Just a thought but would't creating a new file for each year make it more maintainable? I can't imagine searching a 100k line file or scrolling through it.


sort by: page size:

What I don't like about that is most of the entries will be old. I'd love if it had a way to show me only information from the past year.

Not GP, but I have kept a 'logbook' file per year for ten years, with similar contents. I'm sure there's a better way than relying on OS X Spotlight to drum up things from five years ago, but it works well enough for me.

Very interesting... Except I suck at remembering dates.

It would be a cool addition to the directory structure, not a replacement.


6 months is a very long time for this though. I imagine that I would almost never want local history past a day or two. Beyond that I would look to my version control system.

Of course if the data is small why not keep it.


Wouldn't the filesystem suffice for this? It already tracks creation and modification times, so all you'd need to do is sort chronologically in your UI of choice.

If you wanted something Web-based, you could use Google Drive, Dropbox, OneDrive, etc. and get similar functionality.


Why not just restrict the history to a configurable number of entries? Having like 20-50 is probably enough. It might no be 100% correct but the effort:use ratio seems good.

would be very helpful actually... especially since the data is very old and you sometimes have to look at the revision history.

Really need a way to import at least a csv of historical data. I know its pitch is tracking manually makes you more aware, but let me bring in history to start at least. Then we get more use out of it right away. I have years upon years of data, and starting from square one seems like a waste of that data.

Totally love the calendar though, that is a nice way to visualize things.


If you really want to speed it up let users enter the year or use separate drop downs for decade and year.

I agree, if for example you were using this to make date selections far in the past or future there's a LOT of clicking. Unless there's some way to skip years in larger amounts that I just couldn't find in which case there's a discoverability problem.

Damn that would be interesting. I should make a backup of my current one and see how it changes year after year. Good idea!

The Docs versión history tooling is pretty weak, though — you have to repeatedly select a timestamp. You can’t scrub, and you can’t even click on text and get “who put this here, when?”

definitely, but depends on the implementation and usage (e.g. you might want to still keep the “created date”) or “yearly snapshots”, so - not automatic

For every check in we get generate a new build environment, so managing a history file would have been quite difficult.

I guess the downside of this is that ctrl+r would only search the current day's history? Personally I at least increased the history kept with HISTFILESIZE=500000 and HISTSIZE=5000

I like a long history too. I actually automatically rotate my history file every quarter (copying over the 500 most recent entries) and keep around my old history files. It's actually come in really handy when I want to do something I last did two years ago.

I'm slowly adding older papers as I work out the kinks in the site. Down the road when the database is more comprehensive, this should definitely be possible.

Absolutely. Ideally, you'd want both, "append only" and a vintage of the corrected historical data at every point in time. And good metadata.

Great site, but in my experience, the challenge with this kind of thing is designing a (preferably automated) process to keep the data up to date without more work than keeping it running is worth to you. I’d be curious to know if the original author has found ways to automate this, or if he’s somehow maintained a high level of motivation (or if it’s been abandoned).
next

Legal | privacy