Commit Graph

7 Commits (76744d97830781a4f971b0c4d600b23f7f4cbc1d)

Author SHA1 Message Date
Richard Hansen b8d07a42eb lint: Run `eslint --fix` on `bin/` and `tests/` 2020-11-24 20:06:12 +00:00
Richard Hansen 3365e944bf async-ify more functions, and await completion
Where feasible I put the await at the end of the function to
minimize the impact on latency.

My motivation for this change: Eliminate a race condition in tests I
am writing.
2020-09-22 14:10:44 +01:00
brunob edfc7a4916 bin: use correct ueberdb module path "ueberDB" -> "ueberdb2" in tools in /bin
This change is analogous to #2998 (e11decc6f8).
2020-05-15 01:22:41 +02:00
Robin Schneider c9924ee706
Give better error message when rebuildPad.js hits a non-existing rev. 2015-10-07 12:42:19 +02:00
Timothy Chavez c7b1aebfe8 Make changes based on code review
Simplified the cloning process, added validation checks to ensure the
new pad ID is valid and that a pad doesn't already exist with that ID.
Also fixed a bug in the chatHead cloning loop and added the ability to
specify a pad ID on the command the line (defaulting to the original
"-rebuilt" pad ID formula)
2014-12-03 20:11:39 -06:00
Timothy Chavez 25ccb6cfc3 Simplify the rebuild process
The majority of the information needed to build the new pad can be
communicated by simply cloning the rev using a db.set().
2014-11-20 22:09:21 -06:00
Timothy Chavez 01f6d85371 Restore pad to new location at a given revision
This script gives an admin with shell access the ability to restore a
pad at a given revision by essentially rebuilding it at a new location
with data associated with the original pad.  The upsides to creating a
new pad vs. changing the original are: 1) avoiding service disruptions
(no deletes, no moving targets - builds from previous revision); and 2)
preservation of data (no deletes, no overwriting of the source pad).
The most obvious downside is the pad has a new ID which could require
folks to update their links, bookmarks, etc. to point at the new
location.
2014-11-19 13:09:37 -06:00