Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 31 Jan 2013 19:56:55 +0100] rev 18522
hgweb: add a `web.view` to control filtering
This options add a new `web.view` to control filter level of hgweb.
This option have two purposes:
1) Allow fall back to unfiltered version in case a yet undetected by critical
bug is found in filtering after 2.5 release
2) People use hgweb as a local repoviewer. When they have secret changesets,
they wants to use "visible" filter not "served"
(modified by mpm, documentation deferred)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Thu, 31 Jan 2013 22:30:52 +0100] rev 18521
hgweb: returns 404 for unknow revision instead of 500
I noticed that access to filtered revision returned HTTP 500 code (internal
server error). Investigation shown that it was the case for unknown revision
too. That wrong and we now properly return a 404 for revision not found.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Thu, 31 Jan 2013 01:44:29 +0100] rev 18520
subrepo: allows to drop courtesy phase sync (
issue3781)
Publishing server may contains draft changeset when they are created locally. As
publishing is the default, it is actually fairly common. Because of this
"inconsistency" phases synchronization may be done even to publishing server.
This may cause severe issues for subrepo. It is possible to reference read-only
repository as subrepo. Push in a super repo recursively push subrepo. Those
pushes to potential read only repo are not optional, they are "suffered" not
"choosed". This does not break because as the repo is untouched the push is
supposed to be empty. If the reference repo locally contains draft changesets, a
courtesy push is triggered to turn them public. As the repo is read only, the
push fails (after possible prompt asking for credential). Failure of the
sub-push aborts the whole subrepo push. This force the user to define a custom
default-push for such subrepo.
This changeset introduce a prevention of this error client side by skipping the
courtesy phase synchronisation in problematic situation. The phases
synchronisation is skipped when four conditions are gathered:
- this is a subrepo push, (normal push to read-only repo)
- and remote support phase
- and remote is publishing
- and no changesets was pushed (if we pushed changesets, repo is not read only)
The internal config option used in this version is not definitive. It is here to
demonstrate a working fix to the issue.
In the future we probably wants to track subrepo changes and avoid pushing to
untouched one. That will prevent any attempt to push to read-only or unreachable
subrepo.
Another fix to prevent courtesy push from older clients to push to newer server
is also still needed.
Mads Kiilerich <madski@unity3d.com> [Thu, 31 Jan 2013 19:13:13 +0100] rev 18519
tests: fix toctou race in tinyproxy.py (
issue3795)
test-http-proxy.t sometimes failed with:
File ".../tests/tinyproxy.py", line 110, in _read_write
data = i.recv(8192)
error: (104, 'Connection reset by peer')
This might have started showing up with
a9fd11ffa13f ... but it has apparently
also been seen before. I don't see anything in
a9fd11ffa13f that can explain
it. It seems to be a race in test, in the tinyproxy helper:
Tinyproxy found an incoming socket using select(). It would break the loop if
an error had been detected on the socket, but there was no error and it tried
to recv() from the socket. That failed - apparently because it had been reset
after select().
Errors in the recv() will now be caught and will break the loop like errors
detected by select() would.
(send() could also fail in a similar way ... but using the same solution there
and losing data we have read doesn't feel right.)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 01 Feb 2013 02:01:11 +0100] rev 18518
rebase: mention --rev in the help
This changeset adds a small mention of it in the help to prevent
confusion. This small addition references online help that is easier to
update and improve at release time.
Following Wagner Bruna's advice, this is added in a plain new paragraph
to not invalidate current translation this close to the release.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 01 Feb 2013 05:40:06 +0100] rev 18517
hgweb: remove baseline info from paper template
The user interface introduced in
d605a82cf189 is not considered ready
for prime time yet. The internal code stays in place for custom template
usage. The feature is ultimately wanted and will be re-enabled soon. The
current issue is only related to the visual of the current interface.
Kevin Bullock <kbullock@ringworld.org> [Thu, 31 Jan 2013 20:01:26 -0600] rev 18516
rebase: mention phases in the help
Mention that Mercurial helps you not do what you've just been warned not
to do, with a reference to the 'phases' help topic (not the 'phase'
command help).
Thanks to Pierre-Yves David <pierre-yves.david@ens-lyon.org> for
motivating this change and Wagner Bruna
<wagner.bruna+mercurial@gmail.com> for advising on how to do it in an
i18n-friendly way.
Angel Ezquerra <angel.ezquerra@gmail.com> [Thu, 31 Jan 2013 22:36:22 +0100] rev 18515
hgwebdir: use web.prefix when creating url breadcrumbs (
issue3790)
The web.prefix setting was being ignored when creating the index URL
breadcrumbs.
We only need to fix hgwebdir and not hgweb because hgweb gets the complete URL
request, including the prefix, while hgwebdir gets a "subdir" which does not
include the prefix.
This fix is slightly different of what was suggested on the bug tracker. In
there it was suggested to hide the prefix itself from the breadcrumb. I think
that would be a better solution, but it would require changing all the index
templates and passing the prefix to the template engine, which may be too big
a change for stable during the freeze. For now this fixes the problem, and the
fix could be improved during the next cycle.
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Jan 2013 16:08:32 -0800] rev 18514
rebase: delete divergent bookmarks on destination (
issue3685)
Similar to merge, divergent bookmarks are only deleted when the bookmark is on
the destination parent.
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Jan 2013 15:35:00 -0800] rev 18513
bookmarks: factor out delete divergent code
Deleting divergent bookmarks is more generally useful than just in
bookmarks.update.
Siddharth Agarwal <sid0@fb.com> [Wed, 30 Jan 2013 17:49:54 -0800] rev 18512
rebase: remove bogus nullmerge check in updatebookmarks
nstate[v] is a node, not an int, and the nullmerge check was done while
building nstate anyway.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 27 Nov 2012 21:31:59 -0500] rev 18511
share: backout
fd903f89e42b, except the test
Locating the share source when no default path is available is now handled in
subrepo._abssource(), so unconditionally setting a default path (and the
associated problems) can be avoided.
The test change reflects the fact that a default path is no longer set on the
resulting share.
Matt Harbison <matt_harbison@yahoo.com> [Tue, 27 Nov 2012 20:56:27 -0500] rev 18510
subrepo: use sharepath if available when locating the source repo
This is an alternative fix for
issue3518, enabling sharing of repositories with
subrepos, without unconditionally setting the default path in the resulting
repo's hgrc file. Better test coverage is added here, but won't prove this code
is working until
fd903f89e42b is backed out.
The problem with the original fix is, if a default path is not available to be
copied over from the share source, the default path on the resulting repo is set
to the source location. Since that's where the actual repository is stored, the
path is essentially self-referential, so push, pull, incoming and outgoing
effectively operate on itself. While incoming and outgoing make it look like
nothing was changed, push currently hangs (see
issue3657). In this case where
there is not a real default path, these operations should abort with
"default(-push) not found", like the source repo would. Note this problem with
the original fix affected repos without subrepos too.
Pierre-Yves David <pierre-yves.david@logilab.fr> [Tue, 22 Jan 2013 14:33:17 +0100] rev 18509
test-histedit: add tests for dropping head changeset
I got bug report from user in this specific case. I was unable to reproduce in
test situation. Testing this situation is still valuable.