Hi, I had a closer look at the -[COSQLiteStorePersistentRootBackingStore deleteRevids:] method I mentioned.
It turns out that we won't need a separate -forceDeleteRevids: method. -deleteRevids: was always intended to permanently delete the given revisions from disk, it was just buggy / not fully implemented. I corrected the issues in a pull request here: https://github.com/etoile/CoreObject/pull/26 Assuming I didn't miss anything, it should now be possible to implement something like git's interactive rebase / squash, and when you do the next garbage collection on the store, the unreachable revisions will be fully erased from disk. In fact, ProjectDemo might already expose enough features in the UI to already do an interactive rebase (at least, one that just involves skipping over bad revisions). However, ProjectDemo is crashing for me on launch.. will need to investigate that. Cheers, Eric On Tue, Sep 22, 2015 at 2:23 AM, David Chisnall <[email protected]> wrote: > Hi Quentin, Eric, > > I think that the semantic model that I want, from a user perspective, is > something akin to git’s interactive rebase. i.e. select the revision(s) > that want to be permanently deleted, create a new branch starting at the > earliest version before them, selectively apply all of the revisions other > than the deleted ones, then delete the old branch and GC all of the objects. > > If the ‘do the stupid thing’ followed by ‘undo the stupid thing’ revision > are close together, it’s closer to a squash: move the ‘undo the stupid > thing’ revision to immediately after the ‘do the stupid thing’ one, then > combine them into a single commit, with no changes to the state *after* the > two were applied. In particular, if I paste a password then delete the > password, then any revisions that happen after these two changes will be > the same as the ones that were applied first. > > These both seem like things that fit with the conceptual model, if not > with the current APIs. > > David > > > On 21 Sep 2015, at 23:40, Quentin Mathé <[email protected]> wrote: > > > > Hi Eric, David, > > > > Both history compaction and -finalizeDeletionsForPersistentRoot:error: > uses the same logic to delete revisions (see -compactHistory:). > > > > For each branch, when the history is compacted, we figure out a live > revision range bounded by two dead revision ranges (tail and head), so you > cannot specify a revision to be deleted in middle of the live range. In the > same way, there is no garantee that a revision marked as dead is going to > be finalized, due to the delta mechanism as explained by Eric. > > > > A distinct private API -[COSQLiteStorePersistentRootBackingStore > forceDeleteRevids:], with a public API such as -[COSQLiteStore > forceDeleteRevisionUUIDs:forPersistentRootUUID:] seems like a reasonable > first approach. I'm not sure we need a high-level counterpart API, since > it's a pretty rare use case. If we make > -forceDeleteRevisionUUIDs:forPersistentRootUUID: posts a store change > notification stating which persistent root UUID has been "compacted", then > COBranch revisions will automatically get reloaded. > > > > If the unwanted change was recorded on an undo track, the recorded > command will need to be deleted too. This means COUndoTrackStore has be > tweaked to support deleting arbitrary commands, this basically involves > updating parent/child commands. If we do this, it probably makes sense to > extend COHistoryCompaction to accept additional commands for which you want > to force the deletion. Then in -[COSQLiteStore compactHistory:], the > compaction argument would let us know about revisions for which the > deletion is forced, and we could invoke -[COSQLiteStore > forceDeleteRevisionUUIDs:forPersistentRootUUID:] or similar. > > > > Cheers, > > Quentin. > > > >> Le 20 sept. 2015 à 22:55, Eric Wasylishen <[email protected]> a > écrit : > >> > >> Hi David, > >> Yes, that is an important use case, and it's not really possible yet. > >> > >> The lowest level of revision storage is in > COSQLiteStorePersistentRootBackingStore, which resembles the revlog data > structure used by mercurial - an array containing a mix of snapshots of the > object graph and deltas. The backing store has a -deleteRevids: method > which can delete an arbitrary set of revisions. However, this method > doesn't provide a guarantee that the revisions will be erased from disk. > >> It will actually erase the revisions from disk if it's possible to do > so without rebuilding the delta storage - so if you delete the most > recently written revision(s), they will actually be erased. > >> > >> What we would need is a -forceDeleteRevids: method that will rebuild > the delta storage to ensure that those revisions are actually erased from > disk. That would also require that deleting a revision means also deleting > all descendant revisions. > >> > >> Next, this functionality would need to be exposed at higher layers of > the API. > >> COSQLiteStorePersistentRootBackingStore is a private class used in the > implementation of COSQLiteStore. The store API for deletion is > "-finalizeDeletionsForPersistentRoot:error:" which is the same idea as "git > gc" - it deletes revisions from the backing store if they can't be reached > from any of the branch pointers. The COSQLiteStore should probably have a > different API for "please force delete these revisions", and finally we'd > also need an API in COPersistentRoot or COBranch for this. > >> > >> Anyhow, that's my take on it; Quentin recently did some work with > history compaction so maybe he has some other idea on how it could work. > >> Cheers > >> Eric > >> > >> On Sun, Sep 20, 2015 at 6:23 AM, David Chisnall <[email protected]> > wrote: > >> Hi, > >> > >> Is there a mechanism in CoreObject to permanently delete a specific > item from the differential revision history? For example, consider this > sequence: a user hits paste and accidentally pastes a password, rather than > the text that they thought was on the paste buffer, then deletes it, then a > little while later notices that it’s still stored in plain text in the > revision history. It would be nice to expose a UI that allows them to > delete the ‘inserted text “hunter2"’ and 'deleted text “hunter2”’ history > items. Is this currently possible? > >> > >> David > >> > >> > >> -- Sent from my IBM 1620 > >> > >> > >> _______________________________________________ > >> Etoile-dev mailing list > >> [email protected] > >> https://mail.gna.org/listinfo/etoile-dev > >> > >> _______________________________________________ > >> Etoile-dev mailing list > >> [email protected] > >> https://mail.gna.org/listinfo/etoile-dev > > > > > > _______________________________________________ > > Etoile-dev mailing list > > [email protected] > > https://mail.gna.org/listinfo/etoile-dev > > > > > -- Sent from my Difference Engine > > > > > _______________________________________________ > Etoile-dev mailing list > [email protected] > https://mail.gna.org/listinfo/etoile-dev >
_______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
