<br><br><div class="gmail_quote">On Mon, Jun 30, 2008 at 1:53 PM, Avi Bryant <<a href="mailto:avi@dabbledb.com">avi@dabbledb.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Mon, Jun 30, 2008 at 7:57 AM, Colin Putney <<a href="mailto:cputney@wiresong.ca">cputney@wiresong.ca</a>> wrote:<br>
<br>
> The other big problem is that tens of thousands of tiny files is a horribly<br>
> inefficient way to store source code. Yes, disk is cheap. But disk IO is<br>
> not. I discovered this early in the development of MC2, when I implemented a<br>
> type of repository that stored each method in a separate file. Loading<br>
> OmniBrowser from that repository involved opening, reading, and closing over<br>
> 600 files, and was very slow. I don't remember the exact timing, but I think<br>
> it was like 5 to 10 minutes, and in any case it was far too slow. Avi wrote<br>
> a repository that stored every thing in a single indexed file, and now load<br>
> time is dominated by compilation.<br>
<br>
</div>It's worth pointing out that file-based version control has advanced<br>
significantly since we did this work - CVS and SVN are now far from<br>
the state of the art. I haven't used git much, for example, but it<br>
seems to be a well layered system, and it may be that we can build an<br>
alternative front end to its database which is image-based rather than<br>
working directory based. For example, imagine comparing an image<br>
directly to this index file rather than to a directory full of files<br>
on disk:<br>
<br>
<a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index" target="_blank">http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-index</a><br>
<br>
And look at this description of the workflow:<br>
<br>
<a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow" target="_blank">http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow</a><br>
<br>
I personally believe that we're better off with Smalltalk-specific<br>
version control, but if someone *is* looking at integration with more<br>
mainstream tools, I would strongly suggest they start with git rather<br>
than SVN.<br>
<font color="#888888"><br>
Avi<br>
</font></blockquote><div><br>I've been using git quite a bit lately and really like its approach (though I've heard good things about Hg too). I liked it so much that I did a Smalltalk version of it a while back. The idea was to do basically what git does, but make it general purpose such that it could be used for managing versions of any object for which you could define the serialization. I started out making it do version control for contacts and later hooked it up to store Monticello packages (and built a new merge tool in the process). I've had it mostly done for several months but have resisted mentioning it, because once you mention something, you're on the hook to get it out. I'll see if I can clean it up enough in the next few days and publish it. I had hoped to record a screencast to show both how to use it and how the code is currently organized...probably won't do that, but I'll try to get the code out soon.<br>
<br>- Stephen<br></div></div><br>