<div dir="ltr"><div>inline</div><div><br></div>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><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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></div></blockquote><div>I do, in a local file repository for my local libraries. Useful for when I have to reload onto a new image.</div><div>-cbc</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> 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>
<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="HOEnZb"><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></div></div>