Thanks for the great clarification about branches, it makes total
sense.  And, I can understand how a naming-convention would be plenty
good enough for that situation.

If we do choose to adopt / document this convention, we should capture
it in MCVersionName.  :-)



On Mon, Apr 18, 2011 at 2:21 PM, Colin Putney <colin at wiresong.com> wrote:
> On Mon, Apr 18, 2011 at 10:39 AM, Chris Muller <asqueaker at gmail.com> wrote:
>> A GUI tool rendering something like this:
>>
>> MyPackage-cmm.104
>>  ancestors:  (MyPackage-cmm.102  (aVersionInfo))
>>     ancestors:  (MyPackage-cmm.100 (a VersionInfo))
>>        ancestors:  (MyPackage-cmm.99 (a VersionInfo))
>>            ancestors:  (MyPackage-cmm.98 (a VersionInfo))
>>               etc.
>>
>>
>> MyPackage-cmm.103
>>  ancestors:  (MyPackage-cmm.101 (aVersionInfo))
>>    ancestors:  (MyPackage-cmm.100 (a VersionInfo))
>>        ancestors:  (MyPackage-cmm.99 (a VersionInfo))
>>            ancestors:  (MyPackage-cmm.98 (a VersionInfo))
>>               etc.
>>
>>
>> Irregardless of their version-names, 101 and 103 are part of one
>> branch, 102--104 are part of the other branch.
>
> Well, if you click on the History button, you get something like this.
> It doesn't do the indenting, but it lists all the ancestors of the
> selected version.
>
>>>> a branch is based on the ancestry, regardless of how they're
>>>> grouped in the UI.
>>
>> The discussion seems to be centered around using a special
>> naming-scheme that embeds a branch-name into the version-name so the
>> legacy tools can benefit from the side-effect of simple name-string
>> sorting to co-locate the versions of a branch in the UI.
>
> It's a little more than string sorting. A repository browser will
> create a separate entry in the left pane for each branch of a package,
> letting you browse the versions in that branch separately from other
> branches. The attached screen shot shows a couple of branches of
> OmniBrowser in my ob repository. Ok, it's a simple little hack, but it
> makes a big difference in terms of user experience.
>
>> I'm not opposed to naming versions, but what if the tools could
>> already render the actual ancestry model above graphically, which
>> represents the actual branching that took place; perhaps with
>> hover-over to see the version-comments and annotations which indicated
>> the branch-name..
>>
>> I didn't mean to sound so strongly-opinionated; this is just IMHO;
>> which is often changed by learning from the folks in this list..
>
> Ok, let me define a few terms here:
>
> head: a head is a version that has no descendants.
>
> fork: a fork is when there is more than one head for a given package.
>
> Forks happen all the time in concurrent development. I load the latest
> head, then you save a new head, and when I save my work, we've got a
> fork. (Not to be confused with project forks like XEmacs or Pharo.)
> It's no big deal, we just merge, and we're back to the happy
> single-head state for the package.
>
> But sometimes we don't actually want to merge. Sometimes we want to
> stay forked for a while, because the changes made on one fork are
> experimental, or unfinished or whatever. I think that's the definition
> of a branch - a fork that's not the result of happenstance in
> concurrent development, but a deliberate decision to create a separate
> context for development of a package. Branches are forks that remain
> unmerged as a matter of policy. It's also worth noting that forks can
> and do happen within a branch because of concurrent development; they
> just tend to get merged back into a single branch head.
>
> I think what all this means is that branches are purely a social
> phenomenon. It's convenient for us to think about "the oscog branch"
> as a distinct thing, but as far as MC's ancestry records are concerned
> it's no different than if Eliot had a particularly productive hacking
> session on a flight to Singapore.
>
> Now, I agree, an undocumented naming convention that exploits MC's
> display algorithm isn't the best way to support branches. But it's not
> too far off; "proper" support for branches is basically a usability
> issue.
>
> Colin
>
>
>
>