Audit Trail

[BetterRed]

Is there any way to get a session audit trail of changes - perhaps via a command line switch ?

I know I can do a before after compare - but that wont tell what did what, i.e. was it me, was it Sigil, was it a plugin...

BR

[eschwartz]

Are you thinking of an equivalent to calibre's checkpoint feature?

Anyway, Sigil doesn't do a lot of history saving. AFAIK, the only history anywhere is the internal undo/redo of the text editing widgets themselves (which will be trampled by plugins, I think).

Audit trails are at least currently the biggest distinguishing factor between Sigil and calibre.

...

There are no command line switches, although you can at least pass the name of the file it should open with.

[KevinH]

No Sigil is not a concurrent versioning system. Simple whitespace changes and xml order of attributes would be enough to overload most cvs systems with a sea of meaningless changes making what you want hard to find at best. Plugins changes would generate similar reams of meaningless changes.

So exactly what are you trying to track down and why? If reverting changes is important then I would place my epub unpacked into a revision tracker (cvs) and use plugins for import, output, and commit and let the version system track the changes. Just be willing to dig through simple whitespace and order of attribute nonsense when trying to find a specific change.

KevinH

[eschwartz]

Using calibre's checkpoints feature, you can get a pretty good idea of what parts of the EPUB got touched by a plugin.
You can also gloss over the ToC, opf, and other xml-heavy things that probably don't have the changes you are looking for.

It's not quite concurrent versioning, but it is pretty darn handy to see the points where the editor or a plugin changed things, and what they changed. It's not even about reverting -- checkpoints are also an easy way to just run a global replace and confirm the changes, rather than slowly step through each instance.
Or even just seeing the checkpoint titles tells you what tools or plugins have been used!

...

Yes, there is a utility to be found in having such a system (and there are multiple ways to leverage it). Whether everyone needs that, or Sigil needs to focus on providing that, I cannot say.

[KevinH]

No real interest there on my part. Sigil can be used with a cvs or version tracker with a plugin interface if necessary, but it certainly is not going to provide internal checkpointing short of full file save as. Calibre makes use of its own versions of html5lib with changes to use ordered dictionaries to help prevent meaningless attribute order changes. Sigil does not have that option and makes heavy use of QHash which is not order preserving. We could of course build something similar by combining containers (an ordered list of keys alongside the hash) but it simply isn't something I worry about, given a commit plugin could easily handle the insertion and updating into git or any other cvs based system easy enough behind the scenes so to speak, effectively creating book wide versioning.

[eschwartz]

And that is perfectly fair. Different priorities and all that. Sigil has its own strengths (like EPUB3 support).

That's why I said right off the bat, Sigil has no ability to follow changes.

[BetterRed]

Calibres checkpointing won't work in Sigil any more than it'll work in VideoDub. Besides it leaves no 'document' for a green eye-shade wearing 'auditor' wielding a purple pen to pour over in the middle of the night.

Version control will tell me what changed but it wont tell me who dunnit (unless I tell it) - was it me, was it Mend on Open, was it Epub Tidy, some dodgy dude, or smarty pant suited lady.

I was thinking of something like a debug trace - if its not there then not to worry.

BR

[KevinH]

The only way I think to achieve that is to combine some sort of revision storage with an automatic Sigil command logging function of some sort to provide the reason (culprit ) behind each change.

Even With a plugin and git/rcs/cvs system behind it, since these is no automatic sigil command logging, the user would still have to manually make a commit with a commit message explaining what commands caused the changes. So not what you want either.

Sorry.

KevinH

[BetterRed]

Kevin - don't worry about it mate.

I wondered if there might be an undocumented command line switch, or build time option. Not the sort of thing that can be easily retrofitted.

BR

[Doitsu]

@KevinH: How about adding the user name to the epub metadata section each time the dirty bit is set?

In Python you could easily get the user name via:

import getpass
print getpass.getuser()

and the plugin runner code knows the name of the plugin, which would be used instead of the user name.

This way BetterRed could at least check who last updated an ePub.

Of course, this should be an optional feature.

Alternatively, you could have Sigil users define their user name or another custom metadata entry in the settings dialog, which will be added each time a book is saved.

[BetterRed]

Originally Posted by Doitsu

@KevinH: How about adding the user name to the epub metadata section each time the dirty bit is set?
...

@Doitsu - my 'who changed it' was me being tongue-in-cheek facetious (shady characters, smarty pants suit etc). I would only really be interested in 'what changed it'.

But, I don't expect (want) anyone to spend development effort on this on my account - if its not available 'out of the box' I can easily live without it.

I do appreciate your interest though - thanks

BR