Hey Eric, Le 1 nov. 2011 à 22:12, Eric Wasylishen a écrit :
> Hey Quentin & Chris, > >> I think it is equivalent. I was envisioning two tables with the columns >> listed below: >> >> CommitTracks (was called HistoryUnits) >> - UUID >> - CurrentNode >> >> CommitTrackAncestry (was called HistoryRelation in my mail) >> - UUID (the commit track UUID) >> - ParentUUID >> - ParentNode (a commit track node id) >> - Branched (boolean) >> - Public (boolean) > > Sounds really interesting to unify branch, copy, and persistent root, but I > don't fully understand what the columns mean - could you clarify the meaning > of CommitTracks-UUID, > CommitTracks-CurrentNode, CommitTrackAncestry-UUID, > CommitTrackAncestry-ParentUUID, and CommitTrackAncestry-ParentNode? What > other data would be in the store in this model? In this model, there are no persistent roots from the storage perspective. Commit tracks replace them. So a commit track UUID can be a persistent root UUID or a branch UUID. A CommitTrack current node is the "active" revision in the undo track (aka commit track) bound the persistent root or branch. The current node points to a revision in the persistent root or branch history. See Christopher's previous mail about commit tracks and -[COStore setupDB] in ObjectMerging. A CommitTrackAncestry UUID refers to the same persistent root or branch than a CommitTrack UUID. Both are primary keys, CommitTracks and CommitTrackAncestry should probably be merged into a single table. I'm not sure why I suggested two tables previously (probably to make clear we can support commit tracks which are neither branches or persistent roots, but pure undo tracks). When you create a branch or a persistent root copy, a new row is added to the CommitTrackAncestry table, this new row contains: - a parent UUID to known the persistent root from which they derivate - a parent node to know the "active" revision from which they derivate (the "active" revision is a CommitTrack node and refers to a specific revision in the history of the persistent root identified by the parent UUID) In this model, the other data would be the same than what we have currently in ObjectMerging. To implement this model, I would just remove the uuids table in the current model and extend the commitTrack table with the CommitTrackAncestry columns described above. objectuuid in -[COStore setupDB] then refers to a commit track UUID rather than a persistent root UUID, this is the main change implied by this new model. The rest would remain the same I think. > This has been a really interesting discussion thread and I'm getting behind > in replying. :-( In particular, I really liked your comment, Quentin, about > the difficulty of explaining branching to people, and most people wanting > copy and merge. I think making a UI where you can group a copy of an object > with the original object to create a branch, or pull a branch out of an > object to make a freestanding copy is achievable. Yes that seems doable. I think it's important to adapt to the user natural laziness ;-) > After some thought, I think my original NestedVersioning model is really a > bad idea, because it versions data that is immutable (the commit graph)… so > personally I'm leaning towards something closer to ObjectMerging again. I'm > still playing with some different ideas and I'll report back here when I have > something concrete. ok cool :) Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
