[squeak-dev] Urgent, Spur users please read, was: The Inbox: Kernel-kfr.858.mcz

Chris Muller asqueaker at gmail.com
Mon Jun 16 19:21:43 UTC 2014


The practical reason I do not wish to increase our use of branches is
that forces a dependency on MCFileBasedRepository's.  Recall all that
work in 2011(?) to clean up and unify the MCRepository API and reify
MCVersionName so we could support all the other Repository types and
begin to introduce more and better tools?

Then, in 2012, some code to support "branches" that was put into
FileBasedRepository like this:

    (packageName includes: $.) ifTrue: [ "do this" ] ifFalse: [ "do that" ].

If want to be able to use Monticello with any type of MCRepository, we
need to be conservative about the demands we place on our uses of
abstract MCRepository.  Operating strictly within the API declared
there will enable any repository which implements just that API (about
8 methods) to be supported.  Making deeper committments to
FileBased-specific features will further chain us to solely those
types.

> There is nothing to "adopt". This is how MC was designed to handle branches.

All of MC's internal domain functions:  the change reporting, history,
comparing and merging functions; all operate from the
internally-maintained 'ancestry', not any version name that was
entered by the user.

I think you're referring to the convenience of grouping versions of
the same branch together in the Repository inspector UI's list of
versions, is that right?  I'd bet that use-case could be solved
another way -- such as the History button of the WorkingCopy's to
simply look at the ancestry and then select the desired version from
the repository list..

MC's model is fairly beautiful and I think we should stick with the
truth and the beauty.  Multi-use fields are not beautiful, and it's
not clear that MC was "designed to handle branches" because it already
maintains its own first-class Ancestry but nothing first-class about
branches, and no support for them outside of FileBased, and no mention
of them anywhere else in all of MC.

Depending on branch names is fine for individual projects that don't
mind forever depending on FileBased repository's, but IMO we should
not move in that direction as a community's simply for a few Inbox
packages..


On Mon, Jun 16, 2014 at 10:45 AM, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 16.06.2014, at 17:19, Chris Muller <asqueaker at gmail.com> wrote:
>
>> I was trying to understand what _else_ you're saying its for,  :-),
>> and why hacking version-names with one-word "labels" that have nothing
>> to do with the actual ancestry is a good idea for the community at
>> large to adopt?
>
> There is nothing to "adopt". This is how MC was designed to handle branches.
>
> - Bert -
>
>
>
>
>


More information about the Squeak-dev mailing list