1.0 approaches

[Peter Arrenbrecht]

On Feb 8, 2008 10:03 AM, Georg <gwk.rko at googlemail.com> wrote:
> 2008/2/8, Peter Arrenbrecht <peter.arrenbrecht at gmail.com>:
>
>
> > 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
> >
>
> The same intermingling can be seen if you don't use a named branch but
> continue to use branch "default" for your unfinished experiments.
>
> The branch name is just a tag for a "branch" of the tree. There is no harm
> by using the tag, it is the intermingling of unfinished and mature work in
> the same repo which causes harm, potentially.

Forgive me for being stupid, but how do I intermingle stable and
unfinished work in a single branch in such a way that when I push,
others will only consume the stable parts by default? You mean by
working off of separate heads? I'm not sure that works, but even if it
does, I don't think it is something people voluntarily do. The named
branches, however, seem to invite it.
-peo