<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 19, 2013 at 4:08 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">Frank wrote:<br>
<br>
>>> hesitation. Monticello predates git by about 3 years, so we were right...<br>
<div class="im">> Monticello was great, back in the day.<br>
</div>> And now, 7 years of git later, I'd...<br>
<br>
One thing that's usually not a big factor with a lot of Smalltalkers<br>
-- the "age" of the software. In fact that seems a strange thing to<br>
focus on given you're using a 30-year old language in the first<br>
place..<br>
<div class="im"><br>
>>> ahead. It just makes so much sense to me to just use a world class<br>
>>> tool that _we don't have to maintain_. (*)<br>
<br>
</div>It's fine to be impressed with "successful" (translation: used by lots<br>
of developers) bedrock software but we should not trick ourselves into<br>
thinking there's "nothing to do" to use it. The _interface_ to the<br>
SCM...<br>
<div class="im"><br>
> The given error is unfortunate, but that's not even git's fault -<br>
> "Filename too long" says it all. That super long filename comes from<br>
> filetree, so the error's existent is a confluence of a particular<br>
> source->file mapping together with a file system limitation.<br>
<br>
</div>... is not necessarily easier to "maintain" than SCM integrated<br>
directly into the Smalltalk environment. In fact, the domain model is<br>
probably the simplest part of Monticello.<br>
<br>
I think other IDE's use external SCM because they're not an integrated<br>
development "environment" at all. They're a cluster of tools.<br>
Smalltalk is a true integrated environment which I believe ironically<br>
makes using integrated SCM not only possible but just as easy as<br>
interfacing to external.<br></blockquote><div><br></div><div>+1. well said.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
- Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Tue, Nov 19, 2013 at 3:39 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> wrote:<br>
> On 19 November 2013 21:24, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
>> Hi Frank,<br>
>><br>
>> On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 8 November 2013 22:30, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>>> > The trunk is a huge part of the Squeak development process and<br>
>>> > ecosystem that deserves and needs representation somewhere in the<br>
>>> > system. Access to it is reasonably needed by ReleaseBuilder,<br>
>>> > Installer, <a href="http://source.squeak.org" target="_blank">source.squeak.org</a>'s SqueakSource and<br>
>>> > MonticelloConfigurations.<br>
>>><br>
>>> Does noone else in the Squeak community use MCMs? I don't, but my<br>
>>> libraries are all very, very small.<br>
>>><br>
>>> > Squeak has been using its own flavor of Monticello for several years<br>
>>> > now, as does Pharo and GemStone. So, to me, it feels fine to make it<br>
>>> > Monticello-For-Squeak, meaning to relax restrictions imposed by<br>
>>> > multiplatform so it can go as far as we want toward supporting the<br>
>>> > Squeak process.<br>
>>><br>
>>> It's not really germane to this discussion, but if I could flick a<br>
>>> switch and have us updating from github, I would do so without<br>
>>> hesitation. Monticello predates git by about 3 years, so we were right<br>
>>> on the bleeding edge there for a while, but git is now very, very far<br>
>>> ahead. It just makes so much sense to me to just use a world class<br>
>>> tool that _we don't have to maintain_. (*)<br>
>><br>
>><br>
>> Here's an example of why surrendering one's source code control to something<br>
>> else is a really bad idea for an IDE:<br>
><br>
> An IDE _always_ (*) surrenders source code control to something else!<br>
> And it works just fine for emacs, Eclipse, Netbeans, Visual Studio,<br>
> IntelliJ, ...<br>
><br>
> (*) Squeak being the exception<br>
><br>
> The given error is unfortunate, but that's not even git's fault -<br>
> "Filename too long" says it all. That super long filename comes from<br>
> filetree, so the error's existent is a confluence of a particular<br>
> source->file mapping together with a file system limitation.<br>
><br>
>> "When doing a git clone, I do get the following:<br>
>><br>
>><br>
>> Philippe@gravitation7 ~<br>
>> $ git clone --depth=1 <a href="https://github.com/pharo-project/pharo-vm.git" target="_blank">https://github.com/pharo-project/pharo-vm.git</a><br>
>> Cloning into 'pharo-vm'...<br>
>> remote: Counting objects: 17493, done.<br>
>> remote: Compressing objects: 100% (12363/12363), done.<br>
>> remote: Total 17493 (delta 4271), reused 17137 (delta 4143)<br>
>> Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.<br>
>> Resolving deltas: 100% (4271/4271), done.<br>
>> Checking connectivity... done<br>
>> error: unable to create file<br>
>> mc/VMMaker-oscog.package/GeniePlugin.class/instance<br>
>> /primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.<br>
>> mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla<br>
>> g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)<br>
>> Checking out files: 100% (17525/17525), done.<br>
>> fatal: unable to checkout working tree<br>
>> warning: Clone succeeded, but checkout failed.<br>
>> You can inspect what was checked out with 'git status'<br>
>> and retry the checkout with 'git checkout -f HEAD'<br>
>><br>
>> Pretty weird error I'd say.<br>
>><br>
>> Anyone knowing what this is related to?"<br>
>><br>
>> IMO having Monticello under our own control is a key strength. yes, it's<br>
>> effortful to maintain but I don't see why we can't summon that effort. I do<br>
>> fear that if we don't we just become like everything else and soon enough<br>
>> we're just another scripting language. The Smalltalk team had a name for<br>
>> this, something like "error 22", meaning depending on the success of other<br>
>> projects or infrastructure. It's a bad idea, unless its bedrock.<br>
><br>
> Monticello was great, back in the day. But why do we _have_ to saddle<br>
> ourselves with the effort of maintaining it ourselves? What else might<br>
> we _better_ do if we didn't spend all our time NIHing everything?<br>
><br>
> And now, 7 years of git later, I'd consider git to be bedrock. Git<br>
> _has succeeded_. It and mercurial have gutted the competition: darcs,<br>
> monotone, bazaar, ...<br>
><br>
> frank<br>
><br>
>>> > Having said that, I must admit this really does make it<br>
>>> > Squeak-specific, no longer generic. So, maybe an alternative should<br>
>>> > be to model our development process elements in a new package,<br>
>>> > SqueakDevelopmentProcess (?), which would depend on our Squeak's<br>
>>> > generic Monticello to represent the elements of our development<br>
>>> > process.<br>
>>><br>
>>> I'm not terribly concerned with Squeak-specific or otherwise. It's<br>
>>> just that it's _trunk_ specific. I'd rather see a<br>
>>> SqueakDevelopmentProcess package than see it in the Monticello<br>
>>> package.<br>
>>><br>
>>> frank<br>
>>><br>
>>> (*) Finding that switch to flick is pretty hard though, which is why I<br>
>>> don't rant and rave about this all the time. Filetree's OK, but<br>
>>> destroys the ability of browsing source on the git repository (but<br>
>>> gives you the proper fine-grained version control you'd want).<br>
>>> gitfiletree supplies a Pharo UI to filetree, and it would be<br>
>>> worthwhile to port that UI to Squeak, through ToolBuilderification.<br>
>>> Continuing this discussion would necessitate a subject thread change!<br>
>>><br>
>>> > On Fri, Nov 8, 2013 at 3:12 PM, Nicolas Cellier<br>
>>> > <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
>>> >> I have same feeling as Frank,<br>
>>> >> a specific address of a specific repository for a specific usage has<br>
>>> >> not<br>
>>> >> much thing to do in MC.<br>
>>> >> MC package should not integrate each and every possible usage of MC.<br>
>>> >> If this does not belong to ReleaseBuilder, then we can make it a System<br>
>>> >> thing...<br>
>>> >> If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?<br>
>>> >><br>
>>> >><br>
>>> >> 2013/11/8 Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>><br>
>>> >>><br>
>>> >>> MonticelloConfigurations has no dependency on ReleaseBuilder and I<br>
>>> >>> don't think we should introduce one.<br>
>>> >>><br>
>>> >>> If you at least acknowledge "trunk" is a real-thing in the real world,<br>
>>> >>> then note existence of MCRepository>>#trunk. Sure, we could make a<br>
>>> >>> class-var or something if that helps you feel better, but my opinion<br>
>>> >>> right now is that is not necessary because code can change if/when it<br>
>>> >>> needs to. Let's not let maybe-future-pie-in-the-sky-perfect be the<br>
>>> >>> enemy of pragmatic progress in the present.<br>
>>> >>><br>
>>> >>> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar<br>
>>> >>> <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>><br>
>>> >>> wrote:<br>
>>> >>> > On 8 November 2013 15:25, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
>>> >>> >> Chris Muller uploaded a new version of Monticello to project The<br>
>>> >>> >> Trunk:<br>
>>> >>> >> <a href="http://source.squeak.org/trunk/Monticello-cmm.575.mcz" target="_blank">http://source.squeak.org/trunk/Monticello-cmm.575.mcz</a><br>
>>> >>> >><br>
>>> >>> >> ==================== Summary ====================<br>
>>> >>> >><br>
>>> >>> >> Name: Monticello-cmm.575<br>
>>> >>> >> Author: cmm<br>
>>> >>> >> Time: 3 October 2013, 9:42:40.555 pm<br>
>>> >>> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5<br>
>>> >>> >> Ancestors: Monticello-cmm.573<br>
>>> >>> >><br>
>>> >>> >> - Integrate Berts suggestions. Refactored and renamed the API for<br>
>>> >>> >> the<br>
>>> >>> >> new history and origin browsing functions to avoid ambiguity with<br>
>>> >>> >> other MC<br>
>>> >>> >> domain elements. Went from "version" nomenclature to "history".<br>
>>> >>> >> - Related to those functions, browsing a list of patch operations<br>
>>> >>> >> is<br>
>>> >>> >> now abstracted from browsing a Patch. MCPatch is now a<br>
>>> >>> >> MCOperationsList<br>
>>> >>> >> and, likewise, a MCPatchBrowser inherits from a<br>
>>> >>> >> MCOperationsBrowser.<br>
>>> >>> >> - Added well-known repository accessors for #trunk and<br>
>>> >>> >> #packageCache,<br>
>>> >>> >> and #trunkUrlString avoids scattering the hard-coded url string<br>
>>> >>> >> literal in<br>
>>> >>> >> so many places.<br>
>>> >>> ><br>
>>> >>> > I don't like this last item. MCHttpRepository has no business<br>
>>> >>> > knowing<br>
>>> >>> > about any particular location, nor should we commit ourselves to any<br>
>>> >>> > particular repository implementation. For instance, it might make a<br>
>>> >>> > whole lot of sense to build a repository backed by Cassandra.<br>
>>> >>> ><br>
>>> >>> > I'm not convinced that ReleaseBuilder isn't the right place for this<br>
>>> >>> > info. Or, to avoid the double negative, I think ReleaseBuilder is<br>
>>> >>> > the<br>
>>> >>> > place that should know about the trunk URL, because ReleaseBuilder's<br>
>>> >>> > the class responsible for this kind of thing. One kind of release we<br>
>>> >>> > build is a release candidate, for instance.<br>
>>> >>> ><br>
>>> >>> > frank<br>
>>> >>> ><br>
>>> >>><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> ><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> best,<br>
>> Eliot<br>
>><br>
>><br>
>><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>