Excellent discussion. I'm rather distant from OpenSolaris, but I'm studying the
use of Mercurial in our group (Java ME) so I thought I could contribute answers
to some of the questions raised here.
Danek Duvall wrote:
Now, because mercurial doesn't allow you to "hg update" to an unnamed
branch (at least, not in any way I can find), the main development branch
would need to be given a name. I've been using "main" in my test repos,
but it really could be anything.
You can update to an unnamed branch or indeed to any previous rev, simply by
using the command "hg update REV". REV can be a rev number (short or long) or a
branch or a tag name. If this rev is a head, you can append changes to it. If
this rev is an interior node in the history tree, committing to it creates a
new branch (named or unnamed) at this point in the history.
Is the introduction of multiple heads too confusing? Would old ON
developers detest the very idea of multiple heads? (Note that these heads
would never be merged.)
I think it is potentially confusing, since in the typical case, two heads
represent a conflict that needs to be merged. In this case, "hg merge"
implicitly merges with the "other" head. With a mainline head and an arbitrary
number of branch heads, it will always force you to name which head you're
merging with. This is potentially inconvenient and confusing if you have to go
hunting around to figure out which head to merge with.
Those of us un/fortunate enough to have used Subversion will not be bothered by
multiple heads, since in Subversion branches are constantly created but are
never tied back into a mainline. The contents may be merged, but the branch
itself is left dangling.
Mike Kupfer wrote:
> How stable is the named branches support? And is it a first-class,
> well-integrated feature? I thought the philosophy behind Mercurial was
> that a branch is done by cloning the workspace, so I'm a bit concerned
> about named branches being bolted on.
I think a branching tree of history has been around for quite a while in hg,
since it's necessary to support merging of conflicts. The bit about named
branches is more recent, but it's really only a convenient way of labeling a
particular set of revs in a history subtree. Hg certainly supports
Teamware-style development where development is done by cloning the repo and
re-merging. Unfortunately some of the hg docs refer to this technique as
"branching" which only serves to confuse things. I suppose you could say that
hg supports both branching by cloning repos as well as branching within a repo.
Stephen Lau wrote:
> If you look at the image, the central "spine" is the main tree. With
> the branches coming off (tagged in blue). What I was trying to convey
> is that we're used to "tip" being the most recent putback in the main
> tree, i.e.: putback 6. In the branches case, if onnv_60 branched off,
> and there were respins or backouts that came in *after* putback6 went
> in, then "tip" would point to a changeset in the onnv_60 branch, rather
> than the main branch.
Yes, and since the "tip" is by definition the most recent rev, the tip in this
case can flip back and forth between the "spine" and the onnv_60 branch as
respins occur interleaved with normal development.
Danek Duvall wrote:
> Which says to me that "tip" is a useless, if not dangerous, concept. Not
> that this helps us at all.
I agree!
If you're going to proceed with this approach, you probably should ignore the
concept of the tip entirely, and convert over to using named branches. For the
"spine" I'd suggest the term "trunk" (but that's because I have Subversion on
the brain). Then, tell developers always to start with the trunk ("hg update -C
trunk") and to ignore the tip.
s'marks
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
