<div dir="ltr">Hi Frank,<div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 8, 2013 at 2:44 PM, Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">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>
</div>Does noone else in the Squeak community use MCMs? I don't, but my<br>
libraries are all very, very small.<br>
<div class="im"><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>
</div>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></blockquote><div><br></div><div>Here's an example of why surrendering one's source code control to something else is a really bad idea for an IDE:</div><div><br>
</div><div>"When doing a git clone, I do get the following:</div><div><br></div><div><br></div><div>Philippe@gravitation7 ~</div><div>$ git clone --depth=1 <a href="https://github.com/pharo-project/pharo-vm.git">https://github.com/pharo-project/pharo-vm.git</a></div>
<div>Cloning into 'pharo-vm'...</div><div>remote: Counting objects: 17493, done.</div><div>remote: Compressing objects: 100% (12363/12363), done.</div><div>remote: Total 17493 (delta 4271), reused 17137 (delta 4143)</div>
<div>Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done.</div><div>Resolving deltas: 100% (4271/4271), done.</div><div>Checking connectivity... done</div><div>error: unable to create file mc/VMMaker-oscog.package/GeniePlugin.class/instance</div>
<div>/primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.</div><div>mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla</div><div>g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)</div>
<div>Checking out files: 100% (17525/17525), done.</div><div>fatal: unable to checkout working tree</div><div>warning: Clone succeeded, but checkout failed.</div><div>You can inspect what was checked out with 'git status'</div>
<div>and retry the checkout with 'git checkout -f HEAD'</div><div><br></div><div>Pretty weird error I'd say.</div><div><br></div><div>Anyone knowing what this is related to?"</div><div><br></div><div>IMO having Monticello under our own control is a key strength. yes, it's effortful to maintain but I don't see why we can't summon that effort. I do fear that if we don't we just become like everything else and soon enough we're just another scripting language. The Smalltalk team had a name for this, something like "error 22", meaning depending on the success of other projects or infrastructure. It's a bad idea, unless its bedrock.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><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>
</div>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>
<div class=""><div class="h5"><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 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 <<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 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 the<br>
>>> >> new history and origin browsing functions to avoid ambiguity with other MC<br>
>>> >> domain elements. Went from "version" nomenclature to "history".<br>
>>> >> - Related to those functions, browsing a list of patch operations is<br>
>>> >> now abstracted from browsing a Patch. MCPatch is now a MCOperationsList<br>
>>> >> and, likewise, a MCPatchBrowser inherits from a MCOperationsBrowser.<br>
>>> >> - Added well-known repository accessors for #trunk and #packageCache,<br>
>>> >> and #trunkUrlString avoids scattering the hard-coded url string literal in<br>
>>> >> so many places.<br>
>>> ><br>
>>> > I don't like this last item. MCHttpRepository has no business 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 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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>
</div></div>