[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
|