Hi Frank--

> Why do you think that Spoon is a version control system?

     Spoon does include a version control system (Naiad).

> In particular, I would expect a version control system to be able to
> tell me the difference between two arbitrary versions of things. From
> my readings of Spoon's literature (and I'm pretty sure I've read all
> of it), with the caveat that I might have missed or forgotten
> something, I don't think this is something that Spoon can do, or even
> _should_ do.
>
> http://netjam.org/spoon/naiad/ for instance does not describe a
> version control system. Version _aware_ yes.

     Well, with that scheme a subject object memory stores, in a history
object memory, editions describing behavior-related things (class
description, method, author, comment, tag, or module) at different
points in time. The subject memory can ask those editions to compare
themselves (either directly in the history memory, or after being
transferred to the subject memory, as desired).

     To do the comparison, the editions may ask parts of themselves to
compare. For example, method editions might ask method literals to
compare themselves.

> ...in [Naiad], everything _has_ a version, but that doth not a
> version control system make!

     Well, each *edition* has a version (which is just a fancy label),
and describes a class description, method, author, comment, tag, or
module at some point in time. The history memory has editions describing
every change made to every class description, method, author, comment,
tag, and module in the subject memory. It's this edit history that makes
Naiad usable as a version control system.

> What was that thing's parent version? How does it differ from that
> version?

     You can ask an edition for its previous edition, and ask that
previous edition for its version. You can compare editions as described
above.

> Naiad does allow you to say "precisely these objects make up this
> module"...

     Actually, you say "precisely these method editions make up this
module" (you can also specify prerequisite modules).

> ...but that's only one teeny part of a version control system. If you
> like, think of it as a version control system with zero history.

     Hm, the history memory has the entire edit history of the subject
memory since its minimal state. Every time one adds, changes, or removes
something in the subject memory that can be described by an edition,
appropriate editions are added. One can then use the history memory to
access the subject memory's entire edit history over time.

> More to the point, Spoon won't help with the OP's question, namely,
> how to version control _arbitrary binary objects_. And I don't think
> _anyone_ knows: git just stores them, but can't tell you much about
> the difference between two versions of some object.

     I think Lawson and I came up with a way of doing this. We could
have methods that don't correspond to any source code at all, each one
just has some desired object as its sole literal. Then you give the
method a universally-unique selector and store it in the history system
like any other method. You could provide meta info for each version of
that method using Naiad's commenting and tags support. The system
browser could display methods like this in a different way, appropriate
for the object (e.g., a sound player for a sound object).


     thanks,

-C

--
Craig Latta
www.netjam.org/resume
+31   6 2757 7177
+ 1 415  287 3547