[Pharo-dev] [squeak-dev] The .changes file should be bound to a single image

Chris Muller asqueaker at gmail.com
Thu Jun 30 20:31:04 UTC 2016


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


More information about the Squeak-dev mailing list