Sounds like a better idea to me, but I don't think it would solve the problem of multiple images almost simultaneously attempting to update themselves (as in a classroom)

Sent from my iPad

> On Jun 30, 2016, at 13:31, Chris Muller <asqueaker at gmail.com> wrote:
> 
> Another thought...
> 
> Upon launching of the image, start a, temporary changes file,
> [image-name]-[some UUID].changes.
> 
> Upon image save, append the temp changes file to the main changes
> file, but in an atomic way (first do the append as a new unique
> filename, then rename it to the original changes file name).
> 
> Hmm, but then we would have to check two changes files when accessing sources..
> 
> On Thu, Jun 30, 2016 at 3:10 PM, Chris Muller <asqueaker at gmail.com> wrote:
>>>> In practice, this is not an issue that either Chris or I have noticed,
>>>> probably because we are not doing software development (saving method
>>>> changes) at the same time that we are running RemoteTask and similar.
>>>> But I can certainly see how it might be a problem if, for example, I
>>>> had a bunch of students running the same image from a network shared
>>>> folder.
>>> 
>>> Maybe its time to consider a fundamental change in how method-sources
>>> are referred to.
>>> Taking inspiration from git... A content addressable key-value file
>>> store might solve concurrent access.  Each CompiledMethod gets written
>>> to a file named for the hash of its contents, which is the only
>>> reference the Image getsto a method's source.  Each such file would
>> 
>> It sounds like a lot of files.. so how would I move an image to
>> another computer?  I gotta know which files go with which image?
>> 
>> Plus, it doesn't really solve the fundamental problem of two images
>> writing to the same file.  Mutliple images could still change the same
>> method to the same contents at the same time.  You may have made the
>> problem less-likely, except for when you have your first
>> hash-collision of *different* sources (it COULD happen), in which case
>> it wouldn't even require the changes to occur at the same time.
>> 
>> I guess it would also lose the order-sequence of the change log too...
>> unless you were to try to use the underlying filesystem's timestamps
>> on each file but...  it wouldn't work after I've copied all the files
>> via scp and because they all get new timestamps...
>> 
>> Might be better to teach the class, who are learning about Smalltalk
>> anyway, about the nature of the changes file..?
>