On 17 June 2014 02: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.
>
>> 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.

What are you suggesting? That we remove branch support from MC? I hope not...

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

So perhaps the class structures do need redesigning. But a version
control system that doesn't handle branches isn't of much use.

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

That sounds like the tail wagging the dog. A version control system
simply _has to_ support branches. How that plays out in internal data
structures is something that MC's maintainers need to care about, and
no one else.

frank

> Regards,
>   Chris
>