- repository heads are not associated with the closed attribute, so
remove it making the code in line with the concept.
- Fix functions that were calling heads with the parameter.
- Adjust webcommands.branches to include the concept of inactive
as well as open and closed branches
- Fix code and docstrings in commands to make the correct use of
closed branches & branch heads clearer
- Improve grammar of 'hg heads' help text (2nd submission)
this does not alter the cli for hg branches, that work is
still to be done
The repository command, 'branchmap', returns a dictionary, branchname
-> [branchheads], and will be implemented for localrepo, httprepo and
sshrepo.
The following wire format is used for returning data:
branchname1 branch1head2 branch1head2 ...
branchname2 ...
...
Branch names are URL encoded to escape white space, and branch heads
are sent as hex encoded node ids. All branches and all their heads are
sent.
The background and motivation for this command is the desire for a
richer named branch semantics when pushing changesets. The details are
explained in the original proposal which is included below.
1. BACKGROUND
The algorithm currently implemented in Mercurial only considers the
graph theoretical heads when determining whether new heads are
created, rather than using the branch heads as a count (the algorithm
considers a branch head effectively closed when it is merged into
another branch or a new named branch is started from that point
onward).
Our particular problem with the algorithm is that we'd like to see the
following case working without forcing a push:
Upsteam has:
(0:dev) ---- (1:dev)
\
`--- (2:stable)
Someone merges stable into dev:
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) --------´
This can be pushed without --force (as it should).
Now someone else does some coding on stable (a bug fix, say):
(0:dev) ---- (1:dev) ------(3:dev)
\ /
`--- (2:stable) ---------´---------(4:stable)
This time we need --force to push.
We allow this to be pushed without using --force by getting all the
remote branch heads (by extending the wire protocol with a new
function).
We would, furthermore, also prefer if it is impossible to push a new
branch without --force (or a later --newbranch option so --force isn't
shoe-horned into too many disparate functions, if need be), except of
course in the case where the remote repository is empty.
This is what our patches accomplish.
2. ALTERNATIVES
We have, of course, considered some alternatives to reconstructing
enough information to decide whether we are creating new remote branch
heads, before we added the new wire protocol command.
2.1. LOOKUP ON REMOTE
The main alternative is to use the information from remote.heads() and
remote.lookup() to try to reconstruct enough graph information to
decide whether we are creating new heads. This is not adequate as
illustrated below.
Remember that each lookup is typically a request-response pair over
SSH or HTTP(S).
If we have a simple repository at the remote end like this:
(0:dev) ---- (1:dev) ---- (3:stable)
\
`--- (2:dev)
then remote.heads() will yield [2, 3]. Assume we have nodes [0, 1, 2]
locally and want to create a new node, 4:dev, as a descendant from
(1:dev), which should be OK as 1:dev is a branch head.
If we do remote.lookup('dev') we will get [2]. Thus, we can get
information about whether a branch exists on the remote server or not,
but this does not solve our problem of figuring out whether we are
creating new heads or not.
Pushing 4:dev ought to be OK, since after the push, we still only have
two heads on branch a.
Using remote.lookup() and remote.heads() is thus not adequate to
consistently decide whether we are creating new remote heads (e.g. in
this situation the latter would never return 1:dev).
2.2. USING INCOMING TO RECONSTRUCT THE GRAPH
An alternative would be to use information equivalent to hg incoming
to get the full remote graph in addition to the local graph.
To do this, we would have to get a changegroup(subset) bundle
representing the remote end (which may be a substantial amount of
data), getting the branch heads from an instantiated bundlerepository,
deleting the bundle, and finally, we can compute the prepush logic.
While this is backwards compatible, it will cause a possibly
substantial slowdown of the push command as it first needs to pull in
all changes.
3. FURTHER ARGUMENTS IN FAVOUR OF THE BRANCHMAP WIRE-PROTOCOL EXTENSION
Currently, the commands incoming and pull, work based on the tip of a
given branch if used with "-r branchname", making it hard to get all
revisions of a certain branch only (if it has multiple heads). This
can be solved by requesting the remote's branchheads and letting the
revisions to be used with the command be these heads. This can be done
by extending the commands with a new option, e.g.:
hg pull -b branchname
which will be turned into the equivalent of:
hg pull -r branchhead1 -r branchhead2 -r branchhead3
We have a simple follow-up patch that can do this ready as well
(although not submitted yet as it is pending the acceptance of the
branch patch).
4. WRAP-UP
We generally find that the branchmap wire protocol extension can
provide better named branch support to Mercurial. Currently, some
things, like the initial push scenario in this mail, are fairly
counter-intuitive, and the more often you have to force push, the more
it is likely you will get a lot of spurious and unnecessary merge
nodes. Also, restricting incoming and pull to all changes on a branch
rather than changes on the tip-most head would be a sensible extension
to making named branches a first class citizen in Mercurial.
Currently, named branches sometimes feel like a late-coming unwanted
step-child.
We have run it in a production environment for a while, with fewer
multiple heads occurring in our repositories and fewer confused users
as a result.
Also, it fixes the long-standing issue 736.
Co-contributor: Sune Foldager <cryo@cyanite.org>
This allows extensions to hook into permission checking, providing both
authentication and authorization as needed. The existing authorization
function has been changed to a hook, which is added by default.
The property returns os.environ by default, and is propagated by ui.copy.
During hgweb processing, ui.environ is set to the proper WSGI-request
environment, as contained in wsgirequest.environ. For CGI, this is the
same as os.environ.
The property is meant to be read-only, as with os.environ (generally).
Before this patch, the only way to get hgwebdir to honor the recursive paths
was to create a config object or a config file with the recursive paths in it.
This patch makes hgwebdir treat paths the same whether passed in as a list,
tuple, config or however hgwebdir supports passing paths.
The old default behaviour of hgwebdir was to maintain a list of
repositories permanently. This interacted badly with persistent
application hosting software such as WSGI containers. If a new repository
was published, it would potentially never appear in the top-level list
of repositories.
This change causes the hgwebdir configuration and list of repositories
served to be refreshed periodically (at most every 20 seconds).
Before this patch, hgwebdir suddenly showed up empty for a webdir-conf file
that was for some reason not trusted. This was previously not a problem because
the trust mechanism wasn't required for the very separate webdir-conf.
This cleans up code and allows specification of values more globally. For
example, it's now possible to specify web.contact in webdir-conf for all
repositories without a specified contact set.
This avoids hard-coding the '(none)' string in the JavaScript for each
style and avoids the {nonexisting|nonempty} hack which only works
since the template system don't complain about undefined variables.
- create error.py for exception classes to reduce demandloading
- move revlog exceptions to it
- change users to import error and drop revlog import if possible
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
collections: direct child repos only
paths *: direct child repos only (like collections)
paths **: recursive discovery
When ** is used, the mq repository (if any) is also shown.
This feature somehow duplicates [collections] but it is simpler to use and has
less issues under Windows where using absolute path as configuration file key
is not supported.
Suggested by Dirkjan Ochtman <dirkjan@ochtman.nl>
Currently hgweb is not streaming its output -- it accumulates the
entire response before sending it. This patch restores streaming
behaviour. To avoid having to synchronously write many tiny fragments,
this patch also adds buffering to the template generator. Local
testing of a fetch of a 100,000 line file with wget produces a slight
slowdown overall (up from 6.5 seconds to 7.2 seconds), but instead of
waiting 6 seconds for headers to arrive, output begins immediately.
When a manifest has a series of directories with nothing in them but a single
directory, displaying the entire chain of empty directories allows for
navigation down to the first non-empty directory with a single click.
Because Java links package hierarchy to directory hierarchy, and because Java
conventions include at least three empty directories at the top of this
hierarchy, descending down empty directories is very common in Java web tools.
Thanks to Mads Kiilerich with noticing this. The hg client can only read data
after all the sent data has been read, so we have to read all the request data
even if we're not going to do anything with it (in error conditions). This
is not easy to fix in the client, because we're using Python's httplib, which
is strictly stateful. Abstracted the draining into a separate method.
Previously these were served as application/octet-stream usually making
browsers download them as files though they can be displayed inline just
fine. This is useful to refer to e.g. /project/raw-file/tip/README.
This is a new version of b6b16fec2a60 (which was backed out in faf83e1e40f5),
with an extra line removed to fix problems with hg serve. hg's internal web
server contains checking if the app isn't trying to write more bytes than
specified by the Content-Length header. The first try still contained an old
line that wrote the response, so the response was sent twice.
Deleting tmpl just before the return statement should have no effect
since tmpl goes out of scope anyway. But it confuses pyflakes who
thinks tmpl is undefined when it is used in the except blocks below.
Using the write() callable supplied by the start_response() call is
frowned upon by the WSGI spec, returning an iterable over the content chunks
is the recommended way. Be aware, though: returning many small chunks will
slow down responses, because the server has to flush each chunk separately.
Consistently enforces authorization checks set up in hgrc up front, so that
the actual commands don't have to worry about them and implementers of
hgweb alternatives can easily implement their own permission checks.
If the last n charecters of the URL doesn't match an entry in archive_specs
req.form never has a key 'type'. When achive() looks up 'type' in the form
dict it causes a traceback rather than printing an error message.
- make renamelink take a context
- pass current node to shortlog page rather than tip
- pass user/desc/date/rename to filediff
- improve template error reporting for foo%bar
Up to changeset 6713db859c82, HTTP headers were expected to be embedded
in the "headers" template. Since that changeset, the content-type is
supposed to be defined as the "mimetype" template in the map file.
This changeset makes sure the old templates still work.
Turns out that stderr - where ui.warn would send messages - was not
being proxied over the HTTP connection. stdout was, and it seems you
need both. (The streams are interleaved for readability.)
Tested on Ubuntu 7.10 with lighttpd on hgweb.cgi with HTTP Basic auth,
no SSL, using a changeset failing win32text.forbidcrlf.
The error message at startup when the address/port could not be bound
was confusing:
hg serve
abort: cannot start server: Address already in use
Be more explicit:
$ hg serve -a localhost
abort: cannot start server at 'localhost:8000': Address already in use
Also be more explicit on success, showing hostname and ip address/port:
$ hg -v serve -a localhost -p 80
listening at http://localhost/ (127.0.0.1:80)
We are careful to handle a missconfigured machine whose hostname does not
resolve, falling back to the address given at the command line.
Remove a dead-code error message.
The protocol functions are already pretty careful about not raising
exceptions to the caller, and have their own error handling. We can formalize
this a little bit to make it clearer (before, the exception handlers for
a limited number of exceptions coming from the interface bits would blow up
because some variables aren't instantiated for the protocol calls).
This removes the ability for templates to add custom HTTP headers, which can
easily be re-added if someone needs it. Thanks to asak for repeatedly reviewing
this patch and helping to iron out the quirks.
63beab327d26 introduced using ui.username before web.contact, but this was
never documented and might cause commit accidents.
- Drop web.author (deprecated since 2005)
- Try ui.username or $EMAIL as a fallback to display something useful.
- Update docs for the fallbacks.
