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? 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. 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. Regards Eric _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
