>> 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..?