I have same feeling as Frank,
a specific address of a specific repository for a specific usage has not
much thing to do in MC.
MC package should not integrate each and every possible usage of MC.
If this does not belong to ReleaseBuilder, then we can make it a System
thing...
If it's only for MCM, didn't we get a MCMcmUpdater defaultUpdateURL?


2013/11/8 Chris Muller <asqueaker at gmail.com>

> MonticelloConfigurations has no dependency on ReleaseBuilder and I
> don't think we should introduce one.
>
> If you at least acknowledge "trunk" is a real-thing in the real world,
> then note existence of MCRepository>>#trunk.  Sure, we could make a
> class-var or something if that helps you feel better, but my opinion
> right now is that is not necessary because code can change if/when it
> needs to.  Let's not let maybe-future-pie-in-the-sky-perfect be the
> enemy of pragmatic progress in the present.
>
> On Fri, Nov 8, 2013 at 10:33 AM, Frank Shearar <frank.shearar at gmail.com>
> wrote:
> > On 8 November 2013 15:25,  <commits at source.squeak.org> wrote:
> >> Chris Muller uploaded a new version of Monticello to project The Trunk:
> >> http://source.squeak.org/trunk/Monticello-cmm.575.mcz
> >>
> >> ==================== Summary ====================
> >>
> >> Name: Monticello-cmm.575
> >> Author: cmm
> >> Time: 3 October 2013, 9:42:40.555 pm
> >> UUID: daeb51c6-0b6f-41db-883d-e9764e61d8c5
> >> Ancestors: Monticello-cmm.573
> >>
> >> - 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".
> >> - 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.
> >> - Added well-known repository accessors for #trunk and #packageCache,
> and #trunkUrlString avoids scattering the hard-coded url string literal in
> so many places.
> >
> > I don't like this last item. MCHttpRepository has no business knowing
> > about any particular location, nor should we commit ourselves to any
> > particular repository implementation. For instance, it might make a
> > whole lot of sense to build a repository backed by Cassandra.
> >
> > I'm not convinced that ReleaseBuilder isn't the right place for this
> > info. Or, to avoid the double negative, I think ReleaseBuilder is the
> > place that should know about the trunk URL, because ReleaseBuilder's
> > the class responsible for this kind of thing. One kind of release we
> > build is a release candidate, for instance.
> >
> > frank
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131108/35d5ff51/attachment.htm