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

Chris Muller asqueaker at gmail.com
Tue Jun 17 01:35:06 UTC 2014


>> > 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.
>>
>
> We rely on this for maintaining the VMMaker branches, and it works well.

If you're chained to FileBased, it will not work well forever, guaranteed.

> The only new thing that I expect we may need is the ability to specify
> the name of the update map to use for a given branch. For example, the
> update map in the VMMaker project specifies the configuration for the
> trunk (interpreter) branch, and I use that for VMMaker class>>updateFromServer.
> It might be nice if the oscog branch could also have an #updateFromServer,
> presumably specifying the name of a different update map.

Compare the version history of these methods to see how much compexity
branches have brought to the code SINCE the major clean-up and
reification in 2011.

  MCFileRepositoryInspector>>#versionNamesForSelectedPackage
  MCFileBasedRepository>>#versionNamesForPackageNamed:
  MCRepositoryInspector>>#packageHighlight:
  MCFileRepositoryInspector>>#versionNamesForSelectedPackage
  MCRepositoryInspector>>#packageList
  InstallerMonticello>>#mcDetectFileBlock:
  ... the list goes on ...

Any time we see this kind of repeating pattern of case-logic, isn't
that a sign that something needs some re-thinking and possible
re-design?  We really should ask ourselves, critically, do these
"branches" solve any use-case that couldn't possibly be solved by
using separate repositories, existing ancestry, and couple of tweaks?

I doubt it.

> Aside from that, I can't think of any problems with the branch management
> in MC. We certainly have a need to do something like this to support Spur,
> so we may as well use what works.

I think my suggestion would work too, without needing to sell our
independence from FileBased.

Regards,
  Chris


More information about the Squeak-dev mailing list