Track files outside the image

[LeonBein]

This squot extension allows to track changes in files outside the squot images.
This addresses the issue that file changes got lost when merging and that there was no way to select their changes.
The original code and issues can be found here, but there have already been changes made in this fork. 9ea7978 is the first commit that has been made after merging the code from my repo into the fork.

This extension is not yet ready for merging and need to be reviewed, especially to make it comply to the recent changes in squot trunk

[j4yk]

What? There seems to be something fishy here. I have yet to determine the cause.

[j4yk]

I assume pulling the changes from your repository got me a somehow inconsistent image store. It also did not contain the file object at first, as I already commented. Upon committing edb0cf4 I excluded the deletion of the "tracked files" and some other stuff. But I'm not sure if that is related to the problem.

[j4yk]

resetBlock: can only be sent to merge nodes currently, so you need to check whether the node actually has conflicts.

[j4yk]

Branch switching is currently broken:

• In my image it says that I had modified the README.md etc. (which is not true btw, but maybe you do not consider the line ending normalization?).
• When I switch to another branch, it removes the README.md from the disk working copy.
• Later during the switch SquotFileListDiff>>createFile: fails because the README.md is missing.

• It failed while assembling the snapshot of the unsaved changes:

• The SquotFileListDiff looks ok (except for the wrongly detected changes):

This does not seem to work:

updateFile: aPath

	self 
		deleteFile: aPath;
		createFile: aPath.

Source and target seem to be the same in this case. It tries to apply the file modifications on the "modified" files themselves.

When that temporary snapshot is created, the image store must not be modified. So, the Git working copy must not be modified either, in theory.

[j4yk]

I was thinking about this again in the context of #130. My main issue with this contribution was that it makes the image store track files, which are obviously outside of the image. In light of #130 and with the insight that objects need not only be checked out and materialized, but also put up somewhere (in a class variable, in the Smalltalk Environment as a binding or as organization members, or in a directory...) it could make sense to refactor working copies such that each artifact can be put in a different store.

• For unspecialized objects, the image store would still be used as before (one per working copy).
• Unloaded artifacts could use a special "snapshot store" (one per working copy). It would simply not materialize the objects, but keep their snapshots/shadows around, like the unloaded artifacts are implemented in Support "partial checkout" in the image, without removing not-loaded objects on commit #130.
• Packages could go into a Smalltalk Environment store (one per Environment). That would also pull dealing with Environments out of the image store.
• And finally, some artifacts could be put into a file store. Technically it would happen like in the Git backend, but this time targeted at a local disk directory. That could be the file working copy of the git repository, if desired.

Details would need to be though about like how to determine and persist the store to be used for a particular artifact. The information would probably go into the artifact metadata (storeInfo) and the choice to not load something would be a transient property (not stored in Git). But we would need data structures and names, as well as algorithms to arrive at the correct store objects given the metadata structure.