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

Bert Freudenberg bert at freudenbergs.de
Tue Jun 17 11:24:49 UTC 2014


On 17.06.2014, at 03:35, 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.
>>> 
>> 
>> 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.

Again: This is not about files. At all.

>> 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
>  MCRepositoryInspector>>#packageHighlight:
>  MCRepositoryInspector>>#packageList

There is no complexity in these for supporting branches. The only complexity comes from the new browseBranchedVersionsSeparately preference. IMHO we should remove that preference. We do want to browse branches separately, always.

>  InstallerMonticello>>#mcDetectFileBlock:

I think you wouldn't find this objectionable at all if the method was named "withoutVersioning" rather than "packageAndBranchName". All it does is strip author and version number.

>  MCFileBasedRepository>>#versionNamesForPackageNamed:

You are right, this should be moved to MCRepository so it works for all repositories. And possibly be rewritten to not explicitly mention branches. I'm almost sure it could be replaced by

	packageName = mcVersionName withoutVersioning ifTrue: ...

>  ... the list goes on ...

Really? There was only a single method that could be generalized. And it was not made more general initially because it is only used by config maps. Which only support http repos. There was *no need* to have it be more general, but I agree that it would be nicer if all repo kinds had the same interface as far as possible.

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

Renaming methods for nicer readability is good. It also breaks compatibility. We need to decide if that is worth it.

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

The great thing about MC's branches is that you can simply ignore them if you don't need them. You have managed to be unaware of MC branches for years. So that part is working fine. There is some minimal support behind the scenes, sure. You can ignore that, too.

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

Repeating this claim does not make it true. There is no dependency on FileBasedRepositories in the design. If there is one in the code, it is simply a bug.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4142 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140617/5598124c/smime-0001.bin


More information about the Squeak-dev mailing list