Le 07/12/2015 07:13, Martin Bähr a écrit :
Excerpts from Thierry Goubier's message of 2015-12-07 06:42:51 +0100:
i am interested in the versioning of code and objects.
the poster makes a good point there.
The traditional, full approach, would have been to use an object
oriented database like GemStone. Anything that can version objects can
version Smalltalk code.
gemstone is proprietary, so that doesn't really work for me. are there
alternatives?
I have not looked into the alternatives. I know what is needed for a
transparent OO layer for Smalltalk, and I wrote some of the necessary
support code for my PhD in 1997/1998, but I never went very deep into
the versionning aspect (especially the transactions, commits and
conflict resolution).
In short, things are available, a lot of litterature, and maybe some
stuff you can rely upon (the voyage/MongoDB/Sqlite layers we have now?).
what if i am on a non-networked machine, running pharoNOS or even squeakNOS,
how would i keep old versions of my code/objects? is there any in-image
solution for that?
The .changes provides that in a limited form. It would be easy to do
better in memory, if needed.
well, i wouldn't need or even want it in memory, so on disk is fine.
For a moment, I was thinking of systems without disk at all...
the
problem is more likely management of the same. browsing the changes is not
really convenient. ideally i'd like to see versions in the class-browser and
in the debugger, where on error i could then take a look at older versions for
comparison, and switch to them to see if maybe the last change was the cause of
the error.
What you describe is a GUI limitation, not the changes itself :(. A
better integration of the browser/debugger with the code versionning.
And just a local git, fossil or monticello repository would be enough.
All the pieces are there.
As an example, it would be very easy to make AltBrowser browse all the
MC stuff, or RB changes, in addition to the normal (RPackage/Ring) live
code structure (and hence give you access to class versions, method
versions, etc...).
Regards,
Thierry
