On Tue, Jun 17, 2014 at 2:34 AM, Frank Shearar <frank.shearar at gmail.com> wrote:
> 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...

Nope.  I was suggesting that we leave it for the individual projects,
who are now committed to them, and not charge head-on into them as a
community..

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

Why do you imply MC doesn't handle branches without hacking the
version names?  It maintains full ancestry!

So, in effect, MC has TWO disparate mechanisms for supporting
branches, one is the "truth", the other is just a user-entered
pattern-match string that one can only hope matches up with the true
ancestry...

Does anyone know, can the branches support a TRUE hierarcy of
branches?  Something like?

    Morphic.cleaningEffort.cairoSupport-bf.123.mcz

Has this been tested?  Even if it works flawlessly, its ugly.  If not,
then it doesn't deserve to be called a "branch".  Maybe, "sort-tag"
since it's primary use is just to sort in a list.  Crazy bad deal..

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

My suggestion was simply to use the existing version comments!  That's
not tail wagging the dog!  _Branches_ are what brings all that
complexity and sprinkled case-logic and a worse multi-use field and
breakage from the non-FileBased repositories..

I just wish y'all were open to at least TRYING to think of an
alternative (like the one I suggested!), but its clear y'all are dug
in, it seems, just to oppose me personally.  I give up.   :(