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