How can simple version control be implemented for binary objects?

Although it is not a current area of my personal interest, I want to
piggyback on the current discussion about configuration management and
version control with this question, as I think the answer may be
relevant to future projects, such as rich multimedia applications,
rich user interfaces, and active essays.

How can simple version control be implemented for binary objects? I am
thinking of such things as drawings made with the paint tool, and
audio recorded with the sound recorder, as well as compound objects
such as texts with embedded images, formatting and hyperlinks: the
things that web developers call 'assets'.

A reasonable approach seems to be to place an updated image in a
file-based version control system, and then use scripts to keep source
code up-to-date (from a Monticello repository) and build releases.
That requires manual coordination of the assets in a base image.

Another might be to export project files (.pr files also known as
image segments) into a versioned file system such as a webdav server.
Is it easy to use assets in project files? I don't know how difficult
it is to programmatically move objects from project worlds into flaps
or into other worlds.

Does anyone use more fine-grained controls that allow, say, individual
morphs or models to be versioned in multi-developer projects? Is
Morph's fileOut method suitable?

I seem to recall (a year or more ago) that Edgar suggested that such
an objective may be achieved by extending the project / image segment
system. Does that still seem reasonable and has anyone made progress
on that front? Alternatively, is it feasible to extend existing
Smalltalk config management tools in this direction? (I think
Monticello already handles rich hypertext in source code comments, so
could it one day handle more complex objects?)

David

Again, I refer people to the Spoon project.

Lawson

On 2/1/12 5:27 AM, David Corking wrote:

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

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.

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.

frank

On 1 February 2012 17:07, Lawson English <[hidden email]> wrote:

On Wed, Feb 1, 2012 at 6:07 PM, Lawson English <[hidden email]> wrote:
> Again, I refer people to the Spoon project.

I have given info to Craig about the issues I had with running Spoon.

A fine-grained version control would help in Etoys development as
Morph/Player instances
fast become hard to track and takes quite a bit of discipline to
maintain and update a
Etoys project. A system for tracking these changes would be really nice.

Karl

On 2/1/12 10:28 AM, Frank Shearar wrote:
> Why do you think that Spoon is a version control system?
>
> 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://thiscontext.wordpress.com/

See: http://netjam.org/708DEAAF-71C8-4D05-8E2F-63ECBA8FBD8F.html

This is possibly overkill or perhaps not, but it may have ideas for you.

Lawson
>

Frank Shearar wrote:
> git just stores them, but can't tell you much about
> the difference between two versions of some object.

That would be enough to improve Etoys development, for example. We
don't necessarily need to know what changed: there is really only one
feature I seek. We need to have the new object, and be able to
reproduce a configuration that depends on a previous object.
Naturally, it would be nice to know who changed it and when, and read
a commit message, but if we can't tell if its colour or shape or pitch
changed (without looking at it) and we need to store complete copies
of both in a repository, then so be it.

David

On 1 February 2012 18:00, Lawson English <[hidden email]> wrote:
Sure, that's exactly what I mean - in Spoon, everything _has_ a
version, but that doth not a version control system make! What was
that thing's parent version? How does it differ from that version?
Naiad does allow you to say "precisely these objects make up this
module", 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.

I'm certainly not knocking Spoon for not being *ahem* a fork. It's
just that, unless I'm missing something, Spoon's not a version control
system.

frank

> Lawson
>>
>>
>
>

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