On 17 June 2014 16:42, Chris Muller <asqueaker at gmail.com> wrote:
> 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!

I didn't imply that MC doesn't handle branches, but it sure sounded to
me like you thought MC didn't.

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

I don't know what you mean with this. What is "truth" here? Ancestry?
Yes, I agree. And yes, I agree with you (!) that a user-entered
pattern-match string to identify a branch seems like a bit of a fail.
But hey, I measure everything against git anyway, so I'm used to
feeling disappointed. (And I feel disappointed about git from time to
time, just less often than any other VCS I've used.)

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

Erm. "mu". In git, branches can have just about any name, and
"hierarchy" is based on ancestry: branch-a is a child of branch-b if
its ancestry diverges from some commit in branch-b's history. You can
have arbitrarily complex hierarchies of branches, but really, why
would you? Anything more than 2 deep and I'd say your development
process is broken.

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

Comments have no semantic meaning. They're just opaque blobs only of
interest to people. A branch needs to be a first class citizen in a
version control system. And we already have such a thing in MC. A
branch is a commit with a particular format name, and its history
follows the normal MC logic.

OK, the comeback is that the version-name-in-a-commit-name has no
semantic meaning, and are opaque blobs only of interest to people.
Yes, but it's also the way things have always been done in MC.

Oh, there is one distinguishing point: you have to read the comment.
The tooling doesn't support you here, because you'd have to click
around for ages looking at various commits. In contrast putting the
branch name in the version string means the branch name is in your
face in a simple list of commits.

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

Using an entirely separate repository to work around a design flaw - a
bug - seems like massive overkill.

frank