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