Documenting Changes

#1

The post regarding how the haschanged operator works sparked a bit of curiousity in me.

What methids do others use to log their changes to their wiki?

I’m regularly rebuiliding on a tiddlywiki to make it into a template for reuse, sometimes just for the heck of it, and the first things I do is turning off timestamps, and creating a modified tab in the moresidebar tab, so I can track tiddlers.

It’s a bit hacky, but works- so I was wondering if there are any better tips / tricks for doing something like that?

#2

I use a custom “save changes” button:
https://tiddlytools.com/#TiddlyTools%2FSaveChanges
https://tiddlytools.com/#TiddlyTools%2FSaveChanges%2FInfo

When this button is pressed, instead of immediately performing the usual save action, a modal dialog is displayed with a text entry area into which you can enter notes describing the changes you have made during the current session. The modal dialog also has a [+] button that automatically lists all changed non-system tiddlers to make it easier to add notes for each individual tiddler.

When you press the “save file” button in the upper right corner of the modal, the notes (along with a date/time stamp) are added to a “change log” tiddler ($:/state/ChangeLog) and then the file is saved (using whatever “saver handler” you have configured).

The modal dialog also has a “view log” button (eyeball icon, lower left corner) that lets you view/search/copy/edit the change log contents, so you can quickly find and review previously saved notes.

7 Likes
#3

@Justin_H good question. The are however many ways to do this kind of thing and with a different scope. For example I often work on a project basis and I am only concerned with changes within that project. In fact I often just rely on notes to document changes.

  • I have however recently turned my eye to whole of wiki changes and thus the question about haschanged. What is important is you can only identify the changes in the current browser session.
  • There is a special core plugin designed for this purpose “Save Trail” - This plugin causes TiddlyWiki to continuously download (as a JSON file) the contents of any tiddler that is manually changed by any of several means however this may be overkill.
  • Others may rely on the platform that tiddlywiki is running on to keep backups or previous versions of wikis or with node tiddlers.
  • I commonly only retain the N - 1 change version so I can restore something I break.
  • You can also set the username with a view to capturing all changes by that username. The user name could change over time and include a version number. Or you could do a core hack to introduce another field.

I am working on a few mechanisms to support Edition creation, capturing changes to build packages and or bookmarklets and will share back what I learn.

It is great to see @EricShulman’s approach, so lets hope others share their approach.

#4

Referring to EricShulman’s comment:
Ooo, that’s pretty useful.

You wouldn’t happen to have a quick and painless method of pushing changes from a template tw to an active tw would you?

I thought about looking into modifying the upgrader but never had time to poke at it, but I find myself in a predicament where I am using a wiki, and I find something that improves my workflow, and add it to my template wiki, but the non-template wikis would require those, lets call them quality of life tiddler, to be added manually.

It becomes a difficult task when its multiple changes in multiple places or times.

I’m on mobile so I’m a bit constrained, but referring to Tones comment, I like to do a N+3 approach so I can stick to the 3-2-1 rule (3 copies, 2 backups, 1 of which is saved in a different location) but the username to capture those changes is a nice feature.

I have been manually documenting any changes into tiddlers titled “$:/wiki/docs/changelogs/yyyy-0mm-0dd” as the tiddlers are created from shadow tiddlers or imported or normally created, and shown in the modified tab.

#5

FYI: I set a version number on my packages of project tiddlers, containing the release notes and export each version update to the same file. I store the path to the file in the package. Occasionally when a package is stable and I want to install or upgrade it in multiple wikis I turn it into a bookmarklet to apply it with a click.

#6

I’m not too familiar with packaged tiddlers. Do you mean packaged into a plugin, or could it be a node.js sort of feature?

#7

Sorry, the most well known package is bundles created by the bundler plugin, however I just make JSON tiddlers containing multiple tiddlers, when you import such a JSON file, it imports the tiddler within it, as long as you don’t take action to stop it.

  • It is actually very similar to a plugin tiddler but without the plugin-type set to plugin.

If you wanted each time you export a package you could append the version number to the filename.

  • Or write special filter to only export tiddlers that changed since the last export date. That is export packages of changes only or in addition to all tiddlers.
  • If you did export the whole package for every version you could arguably find out what changed each release.

If you search through talk.tiddlywiki you will see I often share solutions as JSON packages. Download and try one.

1 Like
#8

Huh, I’ll need to look into that.

Sidenote, this is a reply to tones’ previous input to the thread, trying to quote text while on mobile is next to impossible because the rightclick menu overlaps the talk.tiddlywiki right click to quote modal.

#9

On my large android there is often sufficient space to select one or the other, but it got a little harder recently. Android 13

1 Like
#10

My use case is probably different to yours, but to maintain the two “MPTW5” editions available here I use some yaml files for the content and some Makefile scripting to build the empties.

I think it would be sensible to use standard .tid files instead of yaml, and I might do that at some point, but for now the yaml, which is converted to json at build time, works fine.

#11

I save revisions to each tiddler:

After about a year of usage, I feel that I don’t use them for the actual information contents of the wiki so much, but during development I use it extensively to see what changes might have broken something, or to go back to a previous revision if I don’t like the result.

Usually when I upgrade the wiki to a new official release, I do a full file backup, after which I delete all revisions to save space. I could then still find these revisions in the backups if needed.

Yaisog

2 Likes
#12

That is excellent @Yaisog I some how missed it.

I will need to package for easy transfer.

#13

I tag (or at least try to) all modified system/plugin tiddlers with tags of the following structure: $:/wilk/tweaks/ShortInfoWhatItDoes.

Advantages:

  • reminds me what this edit was for
  • can find other edits that were made for the same purpose
  • can move to other wiki by dragging tag pill

Disadvantages:

  • not so clear if there is a large number of tweaks, or multiple tweaks due to multiple reasons on the same file
  • no version control or tracking of changes beyond modified timestamp, so it’s not obvious to tell which wiki uses a newer version of the tweak

For the small number of minor changes that I do, I find this solution enough.

#14

Hi Eric,

I use your SaveChanges tool a lot and like it very much. It’s a great way for me to keep track of what I changed. I have a question though. I’ve noticed that if I save and continue editing the next time I save and hit the add changed tiddlers button, that in addition to the tiddlers I just edited, I also get the tiddlers I saved previously. To prevent this, I have to refresh the wiki after a save. Is there any way to be able to only show those tiddlers that were changed since the last save?

Thanks in advance!

#15

TiddlyTools SaveChanges get_changes() uses the TWCore haschanged[] filter operator which returns a list of all tiddlers that have been changed since the start of the current session. When saving the file, the TWCore doesn’t automatically reset this list. As a result, unless you actually reload the wiki after saving the SaveChanges [+] button will produce the results you noted.

The ideal solution would be to have the TWCore internal handling for the this.changeCount[] hashmap reset whenever the wiki is saved (or tiddlers are synced to the server if using nodeJS). Unfortunately, this handling is integrated deep within the TWCore handling of the $tw.wiki object (see $:/core/modules/wiki.js: exports.enqueueTiddlerEvent), so it’s probably best to raise this issue for Jeremy to consider, rather than trying to hack the code myself.

As an alternative, perhaps I can try to make the SaveChanges [+] button “smarter” by excluding any tiddlers whose modification timestamp is earlier than the modification timestamp of the $:/state/ChangeLog tiddler. However, I need to think very carefully about this to ensure that such an approach would work reliably for all use-cases and won’t omit the titles of any tiddlers that actually have been changed.

For example, if you have turned OFF updates to modification timestamps by using the “clock” button in the sidebar Tools tab, or if you’ve saved changes but didn’t add any notes (in which case the modification timestamp for $:/state/ChangeLog isn’t updated). In this case, comparing the tiddler timestamps would not report the desired list of changes that you might expect.

As it stands right now, I feel that its better to report “false positives” rather than running the risk of “false negatives” by omitting changed tiddlers. The workaround response is simply to clear those false positive items from the “notes” input before saving.

-e

#16

Eric could you save changes, save wiki and reload from the one button?

  • no need to reply just a thought bubble :nerd_face:
#17

Also a little research on change count it seems each change increments a title in an array and these are used to determine haschanged[] list.

  • Thus an action widget could be written to clear the changecounts

But depending on the situation I believe the local storage plugin on the wiki offers an approach here to0, because the local storage is only updated when you save the wiki back to the host, however you can reload without loss (clearing change counts),

  • at most the tiddlers loaded from local storage (for which you can get a list) may have a change count of one, ignore for save changes unless => 2
#18

Thanks @EricShulman, that makes perfect sense. I was wondering if something like that was the case. Like you said, it’s easy enough to deal with. Much appreciated.