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
