1.0 approaches

[Peter Arrenbrecht]

On Feb 8, 2008 9:17 AM, Georg <gwk.rko at googlemail.com> wrote:
>
>
> 2008/2/8, Brendan Cully <brendan at kublai.com>:
> > On Thursday, 07 February 2008 at 18:49, Matt Mackall wrote:
> > > There are still some areas with rough edges - named branches and case
> > > sensitivity come to mind. Improvements there that aren't too invasive
> > > will be considered, but these aren't currently going to be considered
> > > showstoppers.
> >
> > In my opinion, named branches in their current form do more harm than
> good.
> > People use them expecting them to behave more like in-repository clones
> > that they can play with and then drop, and usually become frustrated
> > with them, but only after they've permanently cluttered their
> repositories.
> >
> > They also interact badly with clone and older clients, as well as having
> > more benign UI warts.
> >
> > I'd be inclined to discourage their use strongly in 1.0 (maybe relegating
> > them to debugcommands) unless they are improved. I think they will tend to
> > result in bad feelings, whereas most of the rest of mercurial is warm
> > and fuzzy.
>
> I believe you are blurring things.
>
> It is true that you cannot easily drop things that you played with.  I once
> triggered a long thread on that.  I was proposing to add metadata to
> branches (branches in the sense of a part of the version tree, not
> necessarily a named branch) so they can be marked as "obsolete" and maybe
> garbage collected. The thread was not conclusive because throwing away stuff
> in a distributed repository is not easily possible, and mabe not desirable.
>
> But this all holds for simple forks of the tree in the same way as for named
> branches. You just cannot remove.
>
> Don't blame the branch feature for that.  The branch feature only allows you
> to add a descriptive name to your experimental forks.  And that's a very
> good thing.

If I understand this matter correctly, that is not entirely true.
Named branches intermingle commits that are ready for pushing with
others that aren't. So pushed changes have hashes that reference still
unfinished and potentially failed experiments. It's only because of
this intermingling that you cannot simply drop failed experiments
without having to rewrite history, as you can with true clones.
-peo