On 3 May 2013 23:08, Casey Ransberger <casey.obrien.r at gmail.com> wrote:
> Hey Chris,
>
> I read your message and I don't understand the problem you're talking about. I wonder, could you link me/us to the thread where Levente ran into it?
>
> You know I'm still on the fence about Monticello. On the one hand, it fits with the "everything happens in the image," but on the other, it fits with "I can't convince anyone at work to use Smalltalk because it doesn't support industry standard revision control."
>
> It's been proven at this point that we actually *can* use revision control, as long as we deal with our unusual object persistence issues like most people deal with database updates. Because we're a language, an environment, *and* a low-rent object database.

That is a crucial insight, and one I've been trying to come to terms
with. The trunk model is _precisely_ like a database migration. And
that shouldn't be surprising, actually: it's a big bucket of state,
just like any other database.

> Frankly, having the SEO/pop-culture of e.g. GitHub might be of value for this community. Just sayin.'

I can fork a repo just for the sake of fixing a typo in someone's
README, and do it inside of a few minutes. That's pretty potent mojo.

> I'm sure by tomorrow I'll have a small army of complaints about that statement, so to calm that: like I said, I'm still on the fence.

My InstallerGitHub work has stalled while I try figure out why SSL
suddenly broke on my machine (but see
http://build.squeak.org/job/ExternalPackages/123/console). I was
trying to write an Installer that would suck in a GitHub repository in
either chunk format or filetree format. What I found was that
Monticello's a nice way of papering over the nitty gritties of how you
map your objects to the file system. You just load it up into MC
definitions and apply it to the image. I suspect there's a fair bit of
leverage left there, even if you don't end up with mczs in your file
system.

frank

> On May 3, 2013, at 1:04 PM, Chris Muller <asqueaker at gmail.com> wrote:
>
>> We need to be able to develop unrestricted, whether its short and fast
>> rapid-fire one-line commits or larger, slower, deliberated
>> enhancements.
>>
>> We're not in trouble yet but eventually we'll need to address our
>> trunk process implementation limitations.  We've touched on it before;
>> for the FileBasedRepository limitation, Levente had an idea about
>> linking to an archive repository.  Perhaps the recent changes to
>> RepositoryGroup help facilitate this too.  Also there is always
>> GemStone-based SS3 which may not have issues with large scale thanks
>> to being indexed in a DB.
>>
>> That leaves the ancestry issue, in the model where we have:
>>
>>  aVersionInfo
>>      'ancestry' -> anArray(aVersionInfo aVersionInfo)
>>           1-> aVersionInfo
>>               'ancestry' -> anArray(aVersionInfo)
>>                  ....
>>            2-> aVersionInfo
>>                  ...
>>
>> all the way to the first version, including all comment history.
>> mcz's still get bigger and bigger on disk but was thinking about a
>> MCProxy (or maybe just MCVersionInfoStub), which could be used to
>> proxify the tree in memory at least, and bringing it in on demand from
>> its original repositoryGroup if necessary (e.g., during save and if
>> history was requested).
>>
>