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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ob-branches.png
Type: image/png
Size: 22916 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110418/5b13ddb4/ob-branches.png