getting rid of the changes file). Then, saving an MC version is merely a matter of noting the current versions of all the classes/methods in the MC package,
Yea persisting object-representations of the code-domain directly would be real nice; it would eliminate all of the redundancy and wasted disk space that comes with building a new mcz every time.
While Magma can currently be used as a Monticello repository out of the box, but I doubt whether the redundancy is eliminated because I think Monticello builds an entirely new object-structure to fully represent each version, there is no sharing.
It gets hairy when I start to think about multiple images being connected to the db - how do you keep your stuff apart? I haven't thought much about all that, so therefore an RFD here. If people have ideas to share, or comments on the code, I'd be delighted to hear it.
How often do you want the 100th version ago of a method dated back forever? I actually kind of like how getting a new image starts clean with all of the method histories. I usually only care to know what I've been doing *lately*. As great as ENVY was, I don't really miss it; Monticello is too good.
BUT it is short the same thing that ENVY was missing; object resources. While Magma can deliver an arbitrary object-model with a Monticello code repository, there is no associating versions of code with versions of the object model..
- Chris
On 11/4/05, Chris Muller chris@funkyobjects.org wrote:
While Magma can currently be used as a Monticello repository out of the box, but I doubt whether the redundancy is eliminated because I think Monticello builds an entirely new object-structure to fully represent each version, there is no sharing.
Indeed. My current spike logs MCMethod/ClassDefinitions and groups them together under versions. Still needs work, though, for me to be able to reconstruct full snapshots :)
How often do you want the 100th version ago of a method dated back forever? I actually kind of like how getting a new image starts clean with all of the method histories. I usually only care to know what I've been doing *lately*.
Yup. A month back or so, before that you only want stuff that's released. But building in GC will be relatively easy, so I'm not bothering with that right now.
As great as ENVY was, I don't really miss it; Monticello is too good.
Well... there are serious space and performance problems with Monticello. And other issues - I refer to someone here on the list having to manually clean the comment history of a package because it contained proprietary information.
And a feature I sorely miss when compared to ENVY and also StORE is the ability to query the database. In VW, I often find myself going back to the method versions logged in StORE, etcetera.
So, in the land of Smalltalk versioning systems, MC still ranks as 'extremely promising' with me, not yet as 'very good' ;)
On Nov 4, 2005, at 4:24 AM, Cees De Groot wrote:
Indeed. My current spike logs MCMethod/ClassDefinitions and groups them together under versions. Still needs work, though, for me to be able to reconstruct full snapshots :)
Any thoughts, yet, on how you'll handle ancestry? Seems like you've got a few options:
- have each version keep it's own ancestry tree, the way "normal" MC does - intern the VersionInfo instances into a single ancestry graph, and reconstruct each version's ancestry on the fly, similar to snapshots - store ancestry in a different way, and use a different merge algorithm
Well... there are serious space and performance problems with Monticello. And other issues - I refer to someone here on the list having to manually clean the comment history of a package because it contained proprietary information.
And a feature I sorely miss when compared to ENVY and also StORE is the ability to query the database. In VW, I often find myself going back to the method versions logged in StORE, etcetera.
Yes, these are definitely shortcomings of the current system. Slice takes the same approach you're trying here: break these monolithic versions we've got into smaller, independent data-structures, so we don't have nearly so much redundancy.
This gives saves us space, because repository size now grows in proportion to the amount of change in the packages is contains, rather than the number of versions. It also increases speed in the common case, since we no longer have to deal with the full contents of a snapshot when only a few methods have changed. This will be especially important during merges. And finally, having definitions be independently addressable gives us a way to reconstruct the history of single definitions without having to decompress, parse, and scan every version in the respository like we'd have to do in MC1.
It'll be interesting to see where this goes.
Colin
On 11/4/05, Colin Putney cputney@wiresong.ca wrote:
Any thoughts, yet, on how you'll handle ancestry?
An AnvPackageVersion has an ancestry ivar which holds a set of AnvPackageVersions.
It'll be interesting to see where this goes.
Definitely. As I said - Anvil is mostly a spike. Any timeline on MC2 yet?
Am 04.11.2005 um 00:23 schrieb Chris Muller:
It gets hairy when I start to think about multiple images being connected to the db - how do you keep your stuff apart? I haven't thought much about all that, so therefore an RFD here. If people have ideas to share, or comments on the code, I'd be delighted to hear it.
How often do you want the 100th version ago of a method dated back forever? I actually kind of like how getting a new image starts clean with all of the method histories. I usually only care to know what I've been doing *lately*.
In contrast, I often find myself wanting to know what changed in a particular method/class/package lately *especially* when I didn't do it. The version history is something I really miss when starting with a clean image and just loading the latest version of each package.
- Bert -
squeak-dev@lists.squeakfoundation.org