----- Original message -----
> 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)
>
> For a normal branch, we have:
> - a valid Parent (UUID + Node)
> - Branched = true
> - Public = true.
>
> For a private branch (such as a inner branch a la Nested Versioning), we
> have: - a valid Parent
> - Branched = true
> - Public = false
>
> For a new root object (from scratch), we have:
> - no Parent
> - Branched = false
> - Public = true (doesn't really matter in fact)
>
> For a root object copy, we have:
> - a valid Parent
> - Branched = false
> - Public = true (doesn't really matter in fact)
>
> For a root object linked as a precise revision, it is the same than a
> private branch: - a valid Parent
> - Branched = true
> - Public = false.
>
> We surely need some extra rules such as:
> - you cannot branch a commit track if branched is true
>
> We probably need an extra table to store infos related to Branches such
> as their names etc. We might want to move the Public column to this
> table, or introduce a UUID-based owner notion (e.g. an outer document
> owning a inner document branch).
>
> CommitTrackAncestry is not named CommitTrackGraph because to build the
> entire history graph we would need another table that describes the
> merge points.
>
> The current limitation I see with this model is that you cannot support
> live links that automatically reflect their root object current branch.
> It's surely possible to remove this limitation, but to propagate branch
> switches to the related live links doesn't seem like a good idea (too
> hard to predict for the user).
I agree, because the link to a root object should also contain its branch - we
should never store links to objects in documents that reference the notion of a
"current branch", otherwise we get the unhelpful behaviour above.
I don't see how it isn't possible though.
> Let me know if this is close to what you had in mind, and if you see any
> holes in my reasoning…
I can't see any, but I haven't done any serious analysis of it yet.
Chris
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
