Hey David,

On 2011-08-10, at 11:55 AM, David Chisnall wrote:

> Hi Everyone,
> 
> I've had my brain full of LanguageKit for a while, but now it's a bit more 
> functional I'm starting to look at the other bits of Étoilé again.

Cool. :-)

>  In svn, we have CoreObject and ObjectMerging.  I've obviously missed 
> something, because I thought Eric's ObjectMerging branch was the rewritten 
> CoreObject, and the README seems to confirm this, so (in no particular order):
> 
> - What is the relationship between CoreObject and ObjectMerging

ObjectMerging was my attempt at writing a replacement for 
CoreObject+EtoileSeralize. I didn't want to propose calling it "CoreObject" 
unless I actually get it to a somewhat finished state and we decide it's a 
suitable successor/replacement for the current CoreObject. 

There were a few iterations of it in my branch, and Quentin copied the last one 
to trunk/Frameworks/ObjectMerging and has been working on it.
 

To recap the major differences between ObjectMerging and CO:

- It's more "conservative" in that it doesn't try to serialize existing ObjC 
objects. The objects it stores are basically property lists with a UUID label.
- It has diff and merge code. The diff code takes two trees of CoreObjects and 
produces an edit script that transforms the first into the second. The merge 
code attempts to merge these two edit scripts, identifying which (if any) edits 
are conflicting.

> - 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.)

- 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 ran in to some trouble with not formalizing how a UUID reference to an 
object should be interpreted - does it mean "the current version of this object 
on the current branch"? What if we need to refer to a specific, older, version 
of an object?


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!

> - Should we be using one, or some combination of the two?

I was intending for us to use ObjectMerging on its own, if it works out. I 
suppose one could extract the diffing/merging code from ObjectMerging and use 
it with the CoreObject in trunk, though.

> - Is there a high-level overview and tutorial somewhere?

I don't think so, sorry. :-( I hope to write those once ObjectMerging is a bit 
more finalized.

Regards,
Eric
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev

Reply via email to