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: > 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 > > |
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: > Again, I refer people to the Spoon project. > > Lawson > > > On 2/1/12 5:27 AM, David Corking wrote: >> >> 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 >> >> > > |
In reply to this post by LawsonEnglish
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. > > Lawson > > > On 2/1/12 5:27 AM, David Corking wrote: >> >> 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? 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 >> >> 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 >> >> > > |
In reply to this post by Frank Shearar-3
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 > |
In reply to this post by Frank Shearar-3
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 |
In reply to this post by LawsonEnglish
On 1 February 2012 18:00, Lawson English <[hidden email]> wrote:
> 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. 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 >> >> > > |
In reply to this post by Frank Shearar-3
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 |
Free forum by Nabble | Edit this page |