Hi Quentin Thanks for explaining all of that. Its been really useful to discuss this stuff, as alot of new ideas have emerged which I think can make commit tracks better or replace it with something better.
Cheers Chris On 04/11/2011, at 04:12 AM, Quentin Mathé wrote: >>> 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 -------- Christopher Armstrong [email protected] _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
