[squeak-dev] trunk process sustainability

Casey Ransberger casey.obrien.r at gmail.com
Fri May 3 22:08:58 UTC 2013


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


More information about the Squeak-dev mailing list