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). |
On Fri, May 3, 2013 at 1:04 PM, Chris Muller <[hidden email]> wrote: -- We need to be able to develop unrestricted, whether its short and fast I wrote code to coallesce this version info and posted it to the list a couple of years back now. I still have it if you're interested. best, Eliot
|
In reply to this post by Chris Muller-3
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: > 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). > |
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 > On May 3, 2013, at 1:04 PM, Chris Muller <[hidden email]> 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). >> > |
In reply to this post by Chris Muller-3
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: > 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). > > |
In reply to this post by Frank Shearar-3
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 > |
Free forum by Nabble | Edit this page |