Inbox cleaning

> Chris Muller wrote (among other things):
>
>> it's a tool shortfall that can't display the _real_ branches
>
> and:
>
>> No, a branch is based on the ancestry, regardless of how they're
>> grouped in the UI.
>
> You seem to have some pretty strong opinions about branches. Would you
> care to expand on this a little bit? Maybe we can learn something.
>
> Colin
>
>

> On Mon, Apr 18, 2011 at 10:39 AM, Chris Muller <[hidden email]> 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
>
>
>
>

> On 4/19/11, Chris Muller <[hidden email]> wrote:
>> 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.  :-)
>
> Please do so, for people who did not follow this discussion closely
> and after a few weeks it willl be forgotten. However looking at the
> class coment of MCVersionName might not be the most obvious thing to
> do but still it is a likely place where people will stumble upon....
>
> --Hannes
>
>

> I was actually referring to documenting it as _methods_ in
> MCVersionName; not the class-comment (but there's no harm in putting
> it there too).
>
> But before I would do that, I would want to make sure there was
> consensus and then code, tests, inbox, testing, etc..
>
>
> On Tue, Apr 19, 2011 at 4:31 AM, Hannes Hirzel <[hidden email]>
> wrote:
>> On 4/19/11, Chris Muller <[hidden email]> wrote:
>>> 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.  :-)
>>
>> Please do so, for people who did not follow this discussion closely
>> and after a few weeks it willl be forgotten. However looking at the
>> class coment of MCVersionName might not be the most obvious thing to
>> do but still it is a likely place where people will stumble upon....
>>
>> --Hannes
>>
>>
>
>

> On Wed, Apr 20, 2011 at 1:40 AM, Hannes Hirzel <[hidden email]>
> wrote:
>> OK, how do we reach consensus on this?
>
> Well, if we're going to have MCVersionName at all, it should
> definitely have a #branch method. I don't think there's any real
> disagreement here; it's just that different people care more about
> different things. :-)
>
>

> Fine, it is a matter of priorities. How is going to add the #branch
> method to MCVersionName?
>
> --Hannes
>
> On 4/20/11, Colin Putney <[hidden email]> wrote:
>> On Wed, Apr 20, 2011 at 1:40 AM, Hannes Hirzel <[hidden email]>
>> wrote:
>>> OK, how do we reach consensus on this?
>>
>> Well, if we're going to have MCVersionName at all, it should
>> definitely have a #branch method. I don't think there's any real
>> disagreement here; it's just that different people care more about
>> different things. :-)
>>
>>
>

> On Thu, Apr 21, 2011 at 4:48 AM, Hannes Hirzel <[hidden email]> wrote:
>> Fine, it is a matter of priorities. How is going to add the #branch
>> method to MCVersionName?
>>
>
> I'll see if I can do it sometime during the long weekend.
>
> Colin
>
>