<div dir="ltr">Hi Avi,<br><br><div class="gmail_quote">On Tue, Sep 16, 2008 at 11:55 AM, Avi Bryant <span dir="ltr"><<a href="mailto:avi@dabbledb.com" target="_blank">avi@dabbledb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div>On Tue, Sep 16, 2008 at 9:57 AM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>> wrote:<br>
> Yesterday I watched Linus Torvalds talk on G IT at Google. Once you get<br>
> past his obnoxious public persona there is meat here, and its well worth the<br>
> 1 hour 10 minutes holding one's nose. I think he's right on distributed<br>
> version control and so would like to see Monticello GIT integration. One of<br>
> GIT's features that I think will be most synergistic with Smalltalk is that<br>
> it is content addressable. That is, GIT can track the history of a function<br>
> even if it moves from one file to another.<br>
> The system isn't a file tracker, it is a content tracker (in fact, a content<br>
> addressible file system). This removes lots of issues in the mapping of<br>
> Smalltalk methods to whatever the SCM system manages. In GIT there would be<br>
> no problem mapping a class to a file. One could still track the history of<br>
> a method within it with ease and GIT would still transmit only deltas, not<br>
> the entire file, when a part of the method changed.<br>
<br>
</div></div>Yes, see my posts here:<br>
<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html</a><br>
<a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129605.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129605.html</a><br>
<br>
Git is modular enough that one could pretty easily, I think, replace<br>
its directory-of-files <=> content-tree mapping with a smalltalk-image<br>
<=> content-tree mapping and leave the majority of the system intact.<br>
<font color="#888888"><br>
Avi<br></font></blockquote></div><br><div>In <a href="http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html" target="_blank">http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-June/129602.html</a></div>
<div>you state</div><div><span style="color:rgb(136, 136, 136)"><span style="color:rgb(0, 0, 0);font-family:Arial;font-size:16px"><pre style="font-family:monospace;margin-left:3em;font-size:90%">I personally believe that we're better off with Smalltalk-specific
version control, but if someone *is* looking at integration with more
mainstream tools, I would strongly suggest they start with git rather
than SVN.
Avi</pre><span style="font-size:13px">and I want to emphatically agree with you that we want integrated Smalltalk-specific version control. Lets say integrated Smaltalk-centric rathe rthan Smalltalk-specific because there is benefit in other tools & systems being able to access the source repository's contents without using Smalltalk (e.g. web serving, extracting documentation, bootstrapping and I'm sure much more). But none of this prevents using Git as a back-end. Git seems to have several key advantages (that I didn't mention at first; they're in the talk) that we can use.</span></span></span></div>
<div><br></div><div>First, being distributed (based on divergent replicated repositories) there is no centralisation, no dependency on a server which, if it goes down, one can't work without. There is much higher performance because data is local (until one merges by pulling from other repositories). Second, there is protection against corruption (actually corruption detection) because contents are thoroughly check-summed. Most importantly content-addressability means mapping of Smalltalk to files is easier and not much of an issue.</div>
<div><br></div><div>But I'm not sure I buy the mapping of an image to the repository. I would rather browse packages than images (e.g. a packages subdirectory containing a directory per package) and I still want the changes file for crash recovery. But thats a tension right there. Does one keep Smalltalk structures like the changes file and their support or go the whole hog and just use Git for all source? Personally I want to keep as many of the tools in Smalltalk as possible so I can fix and extend them as I'm working. A large wadge of C should be kept in the back ground as much as possible. Its a file system after all.</div>
<div><br></div><div>Eliot</div>
</div>