The pkg(5) gate is open again for business. Note that we're switching to
an internal branch system to keep track of 2010.1H fixes, rather than an
external gate like we did for 2009.06.
Although this should be safe and quite useful, there are some dangers, and
for now, please be careful. In particular, if you use the mercurial
extension cadmium (recommit), you *must* be running build 134 or newer.
Never merge the branches, always use "hg branch" and "hg glog" to check to
see that you're not working on the wrong branch (though you shouldn't be
put onto the 2010.1H branch by accident), and ask me if you're confused, or
need help.
I'm attaching a writeup I did for the core team, which hopefully covers
enough details for those who care to understand what's going on.
Danek
Terminology
===========
In the course of normal development, you may end up forking the changeset
graph and merging it back again as you have changes committed on top of a
particular changeset and pull over changes from the gate that happened in
parallel. These short-lived branches are basically anonymous, and we
continue to not want them in the gate.
Mercurial also uses the term "branch" to describe a separate source
repository which has common history with another one. This is an "external
branch" One example of this is the 2009.06 pkg(5) gate. The teamware model
of maintaining the ON gate is the same.
A "named branch" is internal to the repo (a clone of a single URL brings
over all branches) but has a name. You can refer to the branch by name
with "hg log -b", "hg update", and just about any subcommand which takes a
revision argument. More information than you'll ever want to know can be
found at
http://mercurial.selenic.com/wiki/Branch
and the links from there.
Practice
========
Requirements
------------
If you use cadmium (recommit, in particular), you must be using the module
from build 134. The relevant fix is
6922488 cadmium recommit should be more relaxed about in-repository
branching
Otherwise, the potential is to run into what the slim-install gate did, as
Clay talks about here
http://blogs.sun.com/clayb/entry/mercurial_learning
and here
http://defect.opensolaris.org/bz/show_bug.cgi?id=14991
But there shouldn't be much to it.
The only other new rules to keep in mind are:
- don't merge two named branches
- don't push changesets to more than one branch at a time
The first is really no different than the rule we've always had in place,
which is to never introduce a merge changeset. The second is new, but if
you *are* using cadmium, recommit will refuse to work in such an
environment.
You can switch between branches by running
hg update 2010.03
hg update default
as the branch name used as a changeset revision effectively names the tip
of the named branch.
By default, cloning a gate should update the gate to the "default" branch,
even if the tip changeset isn't on that branch. Similarly, "pull -u" and
"update" won't switch branches unless asked. Once the changeset
introducing the branch has been pushed, you shouldn't be switched to the
2010.03 branch by accident, but please do check before committing (and
pushing) to be absolutely sure.
Note that changes to the .hgtags file (which is how tags are recorded) are
seen in all branches. So tags made on the 2010.03 branch are visible from
the default branch, and vice versa, even though the .hgtags file is
different on the two branches. In general, though, I'd prefer that tags be
created on the appropriate branch.
Tools
-----
I would strongly recommend that you have the graphlog extension configured
in your ~/.hgrc:
[extensions]
hgext.graphlog=
This adds a new hg subcommand, "glog", which is just like "log", but it
prints the node graph to the left of the rest of the information. The "@"
character indicates that the node is the parent of the working directory --
that is, what you've checked out.
The extension also adds a -G option to most subcommands which have "hg
log"-like output to add that graph. In particular, "hg outgoing" now has a
-G option which will display the graph.
If you're pushing a single changeset, there will only be one node in the
graph. If you have several changesets, there will be more than one node:
- if all the nodes are connected in a straight line, then you're safe --
you're pushing a linear set
- if they're connected, but the graph branches or merges, then stop and
ask for help
- if they aren't connected at all, then you've got changesets destined
for different branches, and you should also stop to ask for help
Other useful commands:
- hg branch: shows the named branch of the current working directory
- hg branches: shows all the named branches in the repo
- hg log: shows the branch name for each changeset if it isn't "default"
(the trunk)
- hg view: pops up a graphical (Tk) changeset browser. This requires a
couple of .hgrc mods:
[extensions]
hgext.hgk=
[hgk]
path=/usr/demo/mercurial/hgk
There's also a pretty nice extension called "tortoisehg" which you can
download and install:
http://tortoisehg.bitbucket.org/
Other extensions of interest (to supplant the recommit functionality of
cadmium) are:
- rebase: http://mercurial.selenic.com/wiki/RebaseExtension
This is part of the mercurial package and among other things adds a
--rebase flag to "hg pull", which breaks your local changesets off and
re-merges them onto the new gate tip
- collapse: http://mercurial.selenic.com/wiki/CollapseExtension
This is a simple extension to collapse a run of changesets into a
single changeset
- histedit: http://mercurial.selenic.com/wiki/HisteditExtension
A more complex extension to collapse and reorder changesets
I don't have a whole lot of experience with any of these, but if anyone
wants to noodle around with them, I'm happy to try helping with problems.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
