Hi Shubh ! Sorry, I've been bogged down in a huge package update kerfuffle for ListenBrainz and preparing for the MeB summit, haven't had time to dive in properly
I'll have some time this week to look at it however
Apologies for the delays
Shubh
Ah no problem
Also I'm thinking of working on reverting revisions in BookBrainz
monkey
That would be absolutely great :)
Another potentially cool project is improving the revision diff page which currently sucks
Shubh
Yep, for now it seems changing master revision id on entity header and deleting all references should do the trick.
monkey
deleting all references?
Shubh
deleting new revision from tables like revision, entity_revision, revision_parent and so on
monkey
I'm not sure we want to delete them. Might be prudent to keep the revisions, but change the master revision id
Shubh
Do you think we should allow temporary checkout to old revision?
monkey
I think we should allow reverting to a specific revision. Then if more changes need to be made, the user can create a new revision. Not sure if that answers your question
Shubh
So we want to revert to old revision and still keep the future revisions intact, right?
monkey
That is what I have in mind yes.
Mostly to apply the same concept of preserving editing history; imagine a bad actor goes around and reverts entities' revision to the very first revision; it would be sane to have the ability to essentially revert the revert (AKA putting the latest revision back as master revision)
This creates some questions about whether we want to and how to display branches in editing history, but I think conceptually it is a safer feature
Shubh
I'm thinking of displaying some kind of pointer in entity history page which point to current revision (like HEAD in git) and having a button or something beside each revision which will allow user to revert to that revision.
For first step, I'm thinking of having an option to temporary checkout to a particular revision (like detached Head?) so that user can see how entity looked on that revision, what do you think?
monkey
I think it would be useful to show the diff between current revision and target revision. Not necessarily showing the whole entity, but showing what changes the revision revert will cause
That's good thinking, because the revision diff page won't give users enough info.
And as you say there is no way to show an entity as it was during revision X
Shubh
Achieving this should be easy as will since we just need to use data id associated with that revision only, and other entities should remain as is even if they are related to that revision.
monkey
Well, here's where things get complicated :) Let's say for example I have an Author and a Work. After some time, I added a relationship "Author wrote Work" between the two. Both entities' relationshipSet is modified accordingly.
Now I want to revert my Author to a revision before this relationship was added. What does that mean for us? I would need to also update the Work to remove the relationship in question, otherwise we'll have this relationship only in one direction.
What is our solution here? Do we create a new revision for the Work to remove the relationship to the Author?
Shubh
Each entity has unique relationship set, right?
monkey
That's right.
And each revision of that entity can have a different relationshipset id (although that would be only if rels changed for every revision;)
Shubh
and that set also get updated (new set is assigned) whenever relations get changed for that entity.
monkey
Correct
Shubh
So if we want to just view the old version of an entity, changing data id should work, right?
monkey
Yes, loading an arbitrary revision for an entity should give you all the info to display that entity at that point in time
Shubh
though on revert we need to modify all entities related to that revision.
monkey
Most likely
Well, only if relations are not there anymore
For example if relationships between author and work existed already at revision #123 and i want to revert the author to revision #127, there won't be any change needed for the Work relationship set
Shubh
This info should be captured in the revision itself, so we don't have to worry about this?