trunk process sustainability

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

-- 
best,

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.

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

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.

On May 3, 2013, at 1:04 PM, Chris Muller <[hidden email]> wrote:

On 3 May 2013 23:08, Casey Ransberger <[hidden email]> 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

I uploaded 2 packages related to this to the Inbox. Together they speed up
the update about 3-4 times if there are no changes. Further improvements
are possible, though these don't help with the problems you described.


Levente

On Fri, 3 May 2013, Chris Muller wrote:

Inline and heavily abridged.

On May 3, 2013, at 3:27 PM, Frank Shearar <[hidden email]> wrote:

> On 3 May 2013 23:08, Casey Ransberger <[hidden email]> wrote:
>> BIG SNIP
>>
>> 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.

I think you're right. At first I didn't understand the problem. I think (forgive me if I'm wrong) that it was Dale Henrichs who first said (when I was arguing for mainstream SCM) "there is an impedance mismatch" and that was a revelation, if not a solution. But it got me thinking about a solution. It's kind of half implemented, and I've been treating the code as an unwanted child.

We have to treat both structure and state differently than we treat behavior. We already do that, but I suspect that object-soup tastes so good sometimes that we ignore things we already know from working with other languages.

You can't roll out a database migration in the same way you roll out a code update. Sometimes code is also data, but most people won't recognize that. As such, the rest of the world (meaning: not hard-core enough to appreciate the punk-rock guitar stylings of folks like John McCarthy and Alan Kay, et al.) treats them as completely different.

I think in this case, studying the behavior of the masses and really understanding it might give us as a community new insights toward a better outcome.

We need, in my humblest opinion, to just put on our anthropology hats and really understand a) why b) how c) what the monkeys in the other tribes are doing to deal with having heavily stateful systems.

Okay now I'm done ranting. Love wins? :D

>> BIG SNIP
>