Hi Eric Just a couple of ideas on the points below:
On Thu, 11 Aug 2011 00:57 -0600, "Eric Wasylishen" <[email protected]> wrote: > > - What is the status of ObjectMerging? > > The version that Quentin copied to trunk/Frameworks is somewhat usable, > and has the start of a decent test > suite. The problem is, I'm not happy with the underlying design for a few > reasons: > > - while it's easy to perform undo/redo on the versioned documents, there > is no easy way to implement undo/redo for revision control actions like > "create branch", "switch branch", "revert document to revision", etc. > You could argue that this feature is only nice-to-have and not essential, > but I think it's important for making a revision control system have good > usability (which few, if any, existing systems do! One of my favourite > examples of revision control hidden in an application, the "Develop" > module in Adobe Lightroom for tweaking color/brightness/etc. of photos, > has this feature.) I would have thought that you would put these sorts of operations into the history track. In fact, you would only be able to store the "revert document to revision" in the history track, unless you implement a feature to "name" revisions like branches in git. > - while it handles versioning of simple tree-structured data like > OmniOutliner-like documents, I don't think it will scale up very well to > composite documents. This is because it gives special treatment to > "persistent roots" (these correspond to the version-controlled > documents). History graphs are stored at the persistent root level and > branching can occur only at the persistent root level. Persistent roots > can't be nested, which I think we will need to implement real composite > documents. (This is similar to how branching in git only works at a > whole-repository granularity, so if you have a large codebase you want to > move to git, you have to be careful to decide how you divide it in to git > repositories.) I thought this would be implemented by storing a reference to the persistent root and the revision in the composite document. The main issue is making embedded root objects obvious enough to the user so that they know they are versioned separately and will track the "main branch" of that object, and that changes made to that object outside of the document will be reflected within the document. In addition, you could provide an option to fork the root object into the document, so that changes made to that object are stored as separate revisions, referenced from the document. > Just in the last week or two I've been sketching out a new design which I > hope will resolve these problems. My main idea is to allow the persistent > roots to be nested arbitrarily deep, and to allow the data structures > used for revision control to themselves be versioned, so if you > accidentally delete an important branch, you can just undo that change. > I'm hoping to finalize my new design and try to build a prototype over > the next week. These things always take longer that you expect, but I'll > try to reuse large chunks of the current ObjectMerging, so it should go > more quickly. I'll try to keep everyone up date on my progress! This sounds like the right approach, and similar to what I think I outlined a couple of months back. Regards Chris -- Christopher Armstrong carmstrong ^^AT^ fastmail dOT com /Dot/ au _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
