<div dir="ltr"><div><div><div>I have same feeling as Frank, <br>a specific address of a specific repository for a specific usage has not much thing to do in MC.<br></div>MC package should not integrate each and every possible usage of MC.<br>
</div>If this does not belong to ReleaseBuilder, then we can make it a System thing...<br></div>If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/11/8 Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>> 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 new history and origin browsing functions to avoid ambiguity with other MC domain elements. Went from "version" nomenclature to "history".<br>
>> - Related to those functions, browsing a list of patch operations is now abstracted from browsing a Patch. MCPatch is now a MCOperationsList and, likewise, a MCPatchBrowser inherits from a MCOperationsBrowser.<br>
>> - Added well-known repository accessors for #trunk and #packageCache, and #trunkUrlString avoids scattering the hard-coded url string literal in 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>
</div></div></blockquote></div><br></div>