CoreObject / ObjectMerging

[David Chisnall]

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.  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
- What is the status of ObjectMerging?
- Should we be using one, or some combination of the two?
- Is there a high-level overview and tutorial somewhere?

David

-- Sent from my PDP-11


_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Eric Wasylishen-2]

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
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Christopher Armstrong-5]

Hi Eric

Just a couple of ideas on the points below:

On Thu, 11 Aug 2011 00:57 -0600, "Eric Wasylishen"
<ewasylishen@...> 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
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Eric Wasylishen-2]

Hey,
I'm trying to sketch out some simple model objects which will implement the nested versioning scheme I mentioned earlier. I put it on my github page: https://github.com/ericwa/NestedVersioning
Cheers,
Eric
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Christopher Armstrong-5]

Hi Eric

I'm currently working on the same thing :-)

I've been modifying CoreObject to support this type of model (persistent
"commit" tracks) so that you can branch and undo the branch.
Unfortunately, it breaks COHistoryTrack, and I've been pulling my hair
out trying to get it to support both. I obviously haven't committed it
yet.

Quentin - can I break COHistoryTrack? Maybe in another branch for now?

Regards
Chris

On Wednesday, September 21, 2011 2:42 PM, "Eric Wasylishen"
<ewasylishen@...> wrote:

> Hey,
> I'm trying to sketch out some simple model objects which will implement
> the nested versioning scheme I mentioned earlier. I put it on my github
> page: https://github.com/ericwa/NestedVersioning
> Cheers,
> Eric
> _______________________________________________
> Etoile-dev mailing list
> Etoile-dev@...
> https://mail.gna.org/listinfo/etoile-dev
>

--
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au


_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Eric Wasylishen-2]

Hey Chris,

On 2011-09-21, at 5:15 PM, Christopher Armstrong wrote:

> Hi Eric
>
> I'm currently working on the same thing :-)
>
> I've been modifying CoreObject to support this type of model (persistent
> "commit" tracks) so that you can branch and undo the branch.

Oh, that's cool. :-) I'd be interested in seeing how you approached it.

> Unfortunately, it breaks COHistoryTrack, and I've been pulling my hair
> out trying to get it to support both. I obviously haven't committed it
> yet.

I don't think it's too important if it's broken, because COHistoryTrack was a hackish attempt to get the behaviour I wanted in TestHistoryTrack.m. The test is more interesting, because it tries to test revision control on a somewhat realistic composite document scenario, and nested repositories are the only way I've come up with to get sensible behaviour in that test.

(Not saying that the general idea of building a filtered history graph isn't useful :-)

Eric

> Quentin - can I break COHistoryTrack? Maybe in another branch for now?
>
> Regards
> Chris
>
> On Wednesday, September 21, 2011 2:42 PM, "Eric Wasylishen"
> <ewasylishen@...> wrote:
>> Hey,
>> I'm trying to sketch out some simple model objects which will implement
>> the nested versioning scheme I mentioned earlier. I put it on my github
>> page: https://github.com/ericwa/NestedVersioning
>> Cheers,
>> Eric
>> _______________________________________________
>> Etoile-dev mailing list
>> Etoile-dev@...
>> https://mail.gna.org/listinfo/etoile-dev
>>
> --
>  Christopher Armstrong
>  carmstrong ^^AT^ fastmail dOT com /Dot/ au
>
>
> _______________________________________________
> Etoile-dev mailing list
> Etoile-dev@...
> https://mail.gna.org/listinfo/etoile-dev

_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Christopher Armstrong-5]

Hi Eric

I've posted a patch at https://gna.org/patch/index.php?2964. It contains it as COCommitTrack, and various other fixes to try and support COHistoryTrack and execute unit tests on GNUstep.

Sorry to put it in this form, but I'm going to be away this weekend and am in training next week, and won't have a chance to clean it up and commit it properly until this time next week.

I haven't implemented the undo, but it should merely be a matter of writing a query that updates the commitTrack table's pointer to the previous node. Everything else should be functional, except for the incomplete TestCommitTrack and the one broken part of TestHistoryTrack.m

Cheers

Chris

On 22/09/2011, at 16:25 PM, Eric Wasylishen wrote:

> Hey Chris,
>
> On 2011-09-21, at 5:15 PM, Christopher Armstrong wrote:
>
>> Hi Eric
>>
>> I'm currently working on the same thing :-)
>>
>> I've been modifying CoreObject to support this type of model (persistent
>> "commit" tracks) so that you can branch and undo the branch.
>
> Oh, that's cool. :-) I'd be interested in seeing how you approached it.
>
>> Unfortunately, it breaks COHistoryTrack, and I've been pulling my hair
>> out trying to get it to support both. I obviously haven't committed it
>> yet.
>
> I don't think it's too important if it's broken, because COHistoryTrack was a hackish attempt to get the behaviour I wanted in TestHistoryTrack.m. The test is more interesting, because it tries to test revision control on a somewhat realistic composite document scenario, and nested repositories are the only way I've come up with to get sensible behaviour in that test.
>
> (Not saying that the general idea of building a filtered history graph isn't useful :-)
>
> Eric
>
>> Quentin - can I break COHistoryTrack? Maybe in another branch for now?
>>
>> Regards
>> Chris
>>
>> On Wednesday, September 21, 2011 2:42 PM, "Eric Wasylishen"
>> <ewasylishen@...> wrote:
>>> Hey,
>>> I'm trying to sketch out some simple model objects which will implement
>>> the nested versioning scheme I mentioned earlier. I put it on my github
>>> page: https://github.com/ericwa/NestedVersioning
>>> Cheers,
>>> Eric
>>> _______________________________________________
>>> Etoile-dev mailing list
>>> Etoile-dev@...
>>> https://mail.gna.org/listinfo/etoile-dev
>>>
>> --
>> Christopher Armstrong
>> carmstrong ^^AT^ fastmail dOT com /Dot/ au
>>
>>
>> _______________________________________________
>> Etoile-dev mailing list
>> Etoile-dev@...
>> https://mail.gna.org/listinfo/etoile-dev
>
>
> _______________________________________________
> Etoile-dev mailing list
> Etoile-dev@...
> https://mail.gna.org/listinfo/etoile-dev

--------
Christopher Armstrong
carmstrong@...






_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev

[Quentin Mathé-2]

Hi Christopher,

Le 22 sept. 2011 à 01:15, Christopher Armstrong a écrit :

> Hi Eric
>
> I'm currently working on the same thing :-)
>
> I've been modifying CoreObject to support this type of model (persistent
> "commit" tracks) so that you can branch and undo the branch.
> Unfortunately, it breaks COHistoryTrack, and I've been pulling my hair
> out trying to get it to support both. I obviously haven't committed it
> yet.
>
> Quentin - can I break COHistoryTrack? Maybe in another branch for now?

Feel to break it :-) It doesn't really matter as Eric said.

As a side note, I'm currently away for a two weeks vacations. I should be back on the first days of October.

Cheers,
Quentin.
_______________________________________________
Etoile-dev mailing list
Etoile-dev@...
https://mail.gna.org/listinfo/etoile-dev