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
