2014-08-06 20:43:59 +04:00
|
|
|
#require serve
|
2011-11-07 06:24:53 +04:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
Some tests for hgweb. Tests static files, plain files and different 404's.
|
|
|
|
|
|
|
|
|
|
$ hg init test
|
|
|
|
|
$ cd test
|
|
|
|
|
$ mkdir da
|
|
|
|
|
$ echo foo > da/foo
|
|
|
|
|
$ echo foo > foo
|
|
|
|
|
$ hg ci -Ambase
|
|
|
|
|
adding da/foo
|
|
|
|
|
adding foo
|
hgweb: allow symbolic revisions with forward slashes in urls
It's possible to have a branch/tag/bookmark with all kinds of special
characters, such as {}/\!?. While not very conveniently, symbolic revisions
with such characters work from command line if user correctly quotes the
characters. These characters also work in hgweb, when they are properly
encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
was getting decoded before hgweb could parse it as a part of PATH_INFO.
Because of that, hgweb was seeing it as any other forward slash, that is, as
just another url parts separator.
For example, if user wanted to see the content of dir/file at bookmark
'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
to find a revision 'feature' and get contents of 'eggs/dir/file'.
To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so
CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision
part of the url into an actual '/' character.
Making hgweb produce such urls will be done in the next 2 patches.
2015-07-12 11:06:57 +03:00
|
|
|
$ hg bookmark -r0 '@'
|
|
|
|
|
$ hg bookmark -r0 'a b c'
|
|
|
|
|
$ hg bookmark -r0 'd/e/f'
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -n test -p 0 --port-file $TESTTMP/.port -d --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2010-09-26 22:41:32 +04:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
|
|
manifest
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'file/tip/?style=raw')
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
drwxr-xr-x da
|
|
|
|
|
-rw-r--r-- 4 foo
|
|
|
|
|
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'file/tip/da?style=raw')
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-rw-r--r-- 4 foo
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
plain file
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/foo?style=raw'
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
foo
|
|
|
|
|
|
|
|
|
|
should give a 404 - static file that does not exist
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'static/bogus'
|
2010-09-26 22:41:32 +04:00
|
|
|
404 Not Found
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
|
|
|
|
|
<head>
|
|
|
|
|
<link rel="icon" href="/static/hgicon.png" type="image/png" />
|
|
|
|
|
<meta name="robots" content="index, nofollow" />
|
|
|
|
|
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
|
2011-04-28 19:02:39 +04:00
|
|
|
<script type="text/javascript" src="/static/mercurial.js"></script>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
<title>test: error</title>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<div class="container">
|
|
|
|
|
<div class="menu">
|
|
|
|
|
<div class="logo">
|
2015-09-30 23:43:49 +03:00
|
|
|
<a href="https://mercurial-scm.org/">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/hglogo.png" width=75 height=90 border=0 alt="mercurial" /></a>
|
|
|
|
|
</div>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="/shortlog">log</a></li>
|
|
|
|
|
<li><a href="/graph">graph</a></li>
|
|
|
|
|
<li><a href="/tags">tags</a></li>
|
2011-03-12 13:20:03 +03:00
|
|
|
<li><a href="/bookmarks">bookmarks</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/branches">branches</a></li>
|
2012-07-30 13:33:27 +04:00
|
|
|
</ul>
|
|
|
|
|
<ul>
|
2010-10-10 02:58:48 +04:00
|
|
|
<li><a href="/help">help</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<div class="main">
|
|
|
|
|
|
2013-01-09 04:16:29 +04:00
|
|
|
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
|
2010-09-26 22:41:32 +04:00
|
|
|
<h3>error</h3>
|
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<form class="search" action="/log">
|
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
|
2013-09-06 13:30:57 +04:00
|
|
|
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
|
|
|
|
|
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</form>
|
|
|
|
|
|
|
|
|
|
<div class="description">
|
|
|
|
|
<p>
|
|
|
|
|
An error occurred while processing your request:
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
Not Found
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
[1]
|
|
|
|
|
|
|
|
|
|
should give a 404 - bad revision
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/spam/foo?style=raw'
|
2010-09-26 22:41:32 +04:00
|
|
|
404 Not Found
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
error: revision not found: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
|
|
|
|
should give a 400 - bad command
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/foo?cmd=spam&style=raw'
|
2010-09-26 22:41:32 +04:00
|
|
|
400* (glob)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
error: no such method: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py --headeronly localhost:$HGPORT '?cmd=spam'
|
hgweb: fail if an invalid command was supplied in url path (issue4071)
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
2014-09-22 18:46:38 +04:00
|
|
|
400 no such method: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
|
|
|
|
should give a 400 - bad command as a part of url path (issue4071)
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py --headeronly localhost:$HGPORT 'spam'
|
hgweb: fail if an invalid command was supplied in url path (issue4071)
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
2014-09-22 18:46:38 +04:00
|
|
|
400 no such method: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py --headeronly localhost:$HGPORT 'raw-spam'
|
hgweb: fail if an invalid command was supplied in url path (issue4071)
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
2014-09-22 18:46:38 +04:00
|
|
|
400 no such method: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py --headeronly localhost:$HGPORT 'spam/tip/foo'
|
hgweb: fail if an invalid command was supplied in url path (issue4071)
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
2014-09-22 18:46:38 +04:00
|
|
|
400 no such method: spam
|
|
|
|
|
[1]
|
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
should give a 404 - file does not exist
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/bork?style=raw'
|
2010-09-26 22:41:32 +04:00
|
|
|
404 Not Found
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
error: bork@2ef0ac749a14: not found in manifest
|
|
|
|
|
[1]
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'file/tip/bork'
|
2010-09-26 22:41:32 +04:00
|
|
|
404 Not Found
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
|
|
|
|
|
<head>
|
|
|
|
|
<link rel="icon" href="/static/hgicon.png" type="image/png" />
|
|
|
|
|
<meta name="robots" content="index, nofollow" />
|
|
|
|
|
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
|
2011-04-28 19:02:39 +04:00
|
|
|
<script type="text/javascript" src="/static/mercurial.js"></script>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
<title>test: error</title>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<div class="container">
|
|
|
|
|
<div class="menu">
|
|
|
|
|
<div class="logo">
|
2015-09-30 23:43:49 +03:00
|
|
|
<a href="https://mercurial-scm.org/">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/hglogo.png" width=75 height=90 border=0 alt="mercurial" /></a>
|
|
|
|
|
</div>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="/shortlog">log</a></li>
|
|
|
|
|
<li><a href="/graph">graph</a></li>
|
|
|
|
|
<li><a href="/tags">tags</a></li>
|
2011-03-12 13:20:03 +03:00
|
|
|
<li><a href="/bookmarks">bookmarks</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/branches">branches</a></li>
|
2012-07-30 13:33:27 +04:00
|
|
|
</ul>
|
|
|
|
|
<ul>
|
2010-10-10 02:58:48 +04:00
|
|
|
<li><a href="/help">help</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<div class="main">
|
|
|
|
|
|
2013-01-09 04:16:29 +04:00
|
|
|
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
|
2010-09-26 22:41:32 +04:00
|
|
|
<h3>error</h3>
|
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<form class="search" action="/log">
|
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
|
2013-09-06 13:30:57 +04:00
|
|
|
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
|
|
|
|
|
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</form>
|
|
|
|
|
|
|
|
|
|
<div class="description">
|
|
|
|
|
<p>
|
|
|
|
|
An error occurred while processing your request:
|
|
|
|
|
</p>
|
|
|
|
|
<p>
|
|
|
|
|
bork@2ef0ac749a14: not found in manifest
|
|
|
|
|
</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
[1]
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'diff/tip/bork?style=raw'
|
2010-09-26 22:41:32 +04:00
|
|
|
404 Not Found
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
error: bork@2ef0ac749a14: not found in manifest
|
|
|
|
|
[1]
|
|
|
|
|
|
|
|
|
|
try bad style
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ (get-with-headers.py localhost:$HGPORT 'file/tip/?style=foobar')
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
|
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US">
|
|
|
|
|
<head>
|
|
|
|
|
<link rel="icon" href="/static/hgicon.png" type="image/png" />
|
|
|
|
|
<meta name="robots" content="index, nofollow" />
|
|
|
|
|
<link rel="stylesheet" href="/static/style-paper.css" type="text/css" />
|
2011-04-28 19:02:39 +04:00
|
|
|
<script type="text/javascript" src="/static/mercurial.js"></script>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
<title>test: 2ef0ac749a14 /</title>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<div class="container">
|
|
|
|
|
<div class="menu">
|
|
|
|
|
<div class="logo">
|
2015-09-30 23:43:49 +03:00
|
|
|
<a href="https://mercurial-scm.org/">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/hglogo.png" alt="mercurial" /></a>
|
|
|
|
|
</div>
|
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/shortlog/tip">log</a></li>
|
|
|
|
|
<li><a href="/graph/tip">graph</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/tags">tags</a></li>
|
2011-03-12 13:20:03 +03:00
|
|
|
<li><a href="/bookmarks">bookmarks</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li><a href="/branches">branches</a></li>
|
|
|
|
|
</ul>
|
|
|
|
|
<ul>
|
2015-06-16 11:07:39 +03:00
|
|
|
<li><a href="/rev/tip">changeset</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
<li class="active">browse</li>
|
|
|
|
|
</ul>
|
|
|
|
|
<ul>
|
|
|
|
|
|
2010-10-09 21:27:14 +04:00
|
|
|
</ul>
|
|
|
|
|
<ul>
|
|
|
|
|
<li><a href="/help">help</a></li>
|
2010-09-26 22:41:32 +04:00
|
|
|
</ul>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<div class="main">
|
2013-01-09 04:16:29 +04:00
|
|
|
<h2 class="breadcrumb"><a href="/">Mercurial</a> </h2>
|
2015-06-18 12:06:18 +03:00
|
|
|
<h3>
|
|
|
|
|
directory / @ 0:<a href="/rev/2ef0ac749a14">2ef0ac749a14</a>
|
2017-11-16 17:21:03 +03:00
|
|
|
<span class="phase">draft</span> <span class="branchhead">default</span> <span class="tag">tip</span> <span class="tag">@</span> <span class="tag">a b c</span> <span class="tag">d/e/f</span>
|
2015-06-18 12:06:18 +03:00
|
|
|
</h3>
|
2010-09-26 22:41:32 +04:00
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
<form class="search" action="/log">
|
|
|
|
|
|
2017-06-09 23:59:13 +03:00
|
|
|
<p><input name="rev" id="search1" type="text" size="30" value="" /></p>
|
2013-09-06 13:30:57 +04:00
|
|
|
<div id="hint">Find changesets by keywords (author, files, the commit message), revision
|
|
|
|
|
number or hash, or <a href="/help/revsets">revset expression</a>.</div>
|
2010-09-26 22:41:32 +04:00
|
|
|
</form>
|
|
|
|
|
|
|
|
|
|
<table class="bigtable">
|
2015-02-06 10:52:55 +03:00
|
|
|
<thead>
|
2010-09-26 22:41:32 +04:00
|
|
|
<tr>
|
|
|
|
|
<th class="name">name</th>
|
|
|
|
|
<th class="size">size</th>
|
|
|
|
|
<th class="permissions">permissions</th>
|
|
|
|
|
</tr>
|
2015-02-06 10:52:55 +03:00
|
|
|
</thead>
|
2013-07-13 17:44:46 +04:00
|
|
|
<tbody class="stripes2">
|
|
|
|
|
<tr class="fileline">
|
2015-06-16 11:07:39 +03:00
|
|
|
<td class="name"><a href="/file/tip/">[up]</a></td>
|
2010-09-26 22:41:32 +04:00
|
|
|
<td class="size"></td>
|
|
|
|
|
<td class="permissions">drwxr-xr-x</td>
|
|
|
|
|
</tr>
|
|
|
|
|
|
2013-07-13 17:44:46 +04:00
|
|
|
<tr class="fileline">
|
2010-09-26 22:41:32 +04:00
|
|
|
<td class="name">
|
2015-06-16 11:07:39 +03:00
|
|
|
<a href="/file/tip/da">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/coal-folder.png" alt="dir."/> da/
|
|
|
|
|
</a>
|
2015-06-16 11:07:39 +03:00
|
|
|
<a href="/file/tip/da/">
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
</a>
|
|
|
|
|
</td>
|
|
|
|
|
<td class="size"></td>
|
|
|
|
|
<td class="permissions">drwxr-xr-x</td>
|
|
|
|
|
</tr>
|
|
|
|
|
|
2013-07-13 17:44:46 +04:00
|
|
|
<tr class="fileline">
|
2010-09-26 22:41:32 +04:00
|
|
|
<td class="filename">
|
2015-06-16 11:07:39 +03:00
|
|
|
<a href="/file/tip/foo">
|
2010-09-26 22:41:32 +04:00
|
|
|
<img src="/static/coal-file.png" alt="file"/> foo
|
|
|
|
|
</a>
|
|
|
|
|
</td>
|
|
|
|
|
<td class="size">4</td>
|
|
|
|
|
<td class="permissions">-rw-r--r--</td>
|
|
|
|
|
</tr>
|
2013-07-13 17:44:46 +04:00
|
|
|
</tbody>
|
2010-09-26 22:41:32 +04:00
|
|
|
</table>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
</body>
|
|
|
|
|
</html>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
stop and restart
|
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve -p 0 --port-file $TESTTMP/.port -d --pid-file=hg.pid -A access.log
|
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2010-09-26 22:41:32 +04:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
|
|
|
|
Test the access/error files are opened in append mode
|
|
|
|
|
|
2014-10-15 23:35:59 +04:00
|
|
|
$ $PYTHON -c "print len(file('access.log').readlines()), 'log lines written'"
|
hgweb: fail if an invalid command was supplied in url path (issue4071)
Traditionally, the way to specify a command for hgweb was to use url query
arguments (e.g. "?cmd=batch"). If the command is unknown to hgweb, it gives an
error (e.g. "400 no such method: badcmd").
But there's also another way to specify a command: as a url path fragment (e.g.
"/graph"). Before, hgweb was made forgiving (looks like it was made in
cd356f4efd91) and user could put any unknown command in the url. If hgweb
couldn't understand it, it would just silently fall back to the default
command, which depends on the actual style (e.g. for paper it's shortlog, for
monoblue it's summary). This was inconsistent and was breaking some tools that
rely on http status codes (as noted in the issue4071). So this patch changes
that behavior to the more consistent one, i.e. hgweb will now return "400 no
such method: badcmd".
So if some tool was relying on having an invalid command return http status
code 200 and also have some information, then it will stop working. That is, if
somebody typed foobar when they really meant shortlog (and the user was lucky
enough to choose a style where the default command is shortlog too), that fact
will now be revealed.
Code-wise, the changed if block is only relevant when there's no "?cmd" query
parameter (i.e. only when command is specified as a url path fragment), and
looks like the removed else branch was there only for falling back to default
command. With that removed, the rest of the code works as expected: it looks at
the command, and if it's not known, raises a proper ErrorResponse exception
with an appropriate message.
Evidently, there were no tests that required the old behavior. But, frankly, I
don't know any way to tell if anyone actually exploited such forgiving behavior
in some in-house tool.
2014-09-22 18:46:38 +04:00
|
|
|
14 log lines written
|
2010-09-26 22:41:32 +04:00
|
|
|
|
|
|
|
|
static file
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py --twice localhost:$HGPORT 'static/style-gitweb.css' - date etag server
|
2010-09-26 22:41:32 +04:00
|
|
|
200 Script output follows
|
2017-12-01 15:33:02 +03:00
|
|
|
content-length: 9152
|
2013-01-15 23:54:57 +04:00
|
|
|
content-type: text/css
|
2010-09-26 22:41:32 +04:00
|
|
|
|
2015-10-07 23:08:14 +03:00
|
|
|
body { font-family: sans-serif; font-size: 12px; border:solid #d9d8d1; border-width:1px; margin:10px; background: white; color: black; }
|
2010-09-26 22:41:32 +04:00
|
|
|
a { color:#0000cc; }
|
|
|
|
|
a:hover, a:visited, a:active { color:#880000; }
|
|
|
|
|
div.page_header { height:25px; padding:8px; font-size:18px; font-weight:bold; background-color:#d9d8d1; }
|
|
|
|
|
div.page_header a:visited { color:#0000cc; }
|
|
|
|
|
div.page_header a:hover { color:#880000; }
|
2017-06-09 23:55:51 +03:00
|
|
|
div.page_nav {
|
|
|
|
|
padding:8px;
|
|
|
|
|
display: flex;
|
|
|
|
|
justify-content: space-between;
|
|
|
|
|
align-items: center;
|
|
|
|
|
}
|
2010-09-26 22:41:32 +04:00
|
|
|
div.page_nav a:visited { color:#0000cc; }
|
2017-06-21 06:53:29 +03:00
|
|
|
div.extra_nav {
|
|
|
|
|
padding: 8px;
|
|
|
|
|
}
|
|
|
|
|
div.extra_nav a:visited {
|
|
|
|
|
color: #0000cc;
|
|
|
|
|
}
|
2010-09-26 22:41:32 +04:00
|
|
|
div.page_path { padding:8px; border:solid #d9d8d1; border-width:0px 0px 1px}
|
|
|
|
|
div.page_footer { padding:4px 8px; background-color: #d9d8d1; }
|
|
|
|
|
div.page_footer_text { float:left; color:#555555; font-style:italic; }
|
|
|
|
|
div.page_body { padding:8px; }
|
|
|
|
|
div.title, a.title {
|
|
|
|
|
display:block; padding:6px 8px;
|
|
|
|
|
font-weight:bold; background-color:#edece6; text-decoration:none; color:#000000;
|
|
|
|
|
}
|
|
|
|
|
a.title:hover { background-color: #d9d8d1; }
|
|
|
|
|
div.title_text { padding:6px 0px; border: solid #d9d8d1; border-width:0px 0px 1px; }
|
|
|
|
|
div.log_body { padding:8px 8px 8px 150px; }
|
|
|
|
|
.age { white-space:nowrap; }
|
|
|
|
|
span.age { position:relative; float:left; width:142px; font-style:italic; }
|
|
|
|
|
div.log_link {
|
|
|
|
|
padding:0px 8px;
|
|
|
|
|
font-size:10px; font-family:sans-serif; font-style:normal;
|
|
|
|
|
position:relative; float:left; width:136px;
|
|
|
|
|
}
|
|
|
|
|
div.list_head { padding:6px 8px 4px; border:solid #d9d8d1; border-width:1px 0px 0px; font-style:italic; }
|
|
|
|
|
a.list { text-decoration:none; color:#000000; }
|
|
|
|
|
a.list:hover { text-decoration:underline; color:#880000; }
|
|
|
|
|
table { padding:8px 4px; }
|
|
|
|
|
th { padding:2px 5px; font-size:12px; text-align:left; }
|
2016-07-16 10:00:36 +03:00
|
|
|
.parity0 { background-color:#ffffff; }
|
2015-10-14 19:04:58 +03:00
|
|
|
tr.dark, .parity1, pre.sourcelines.stripes > :nth-child(4n+4) { background-color:#f6f6f0; }
|
|
|
|
|
tr.light:hover, .parity0:hover, tr.dark:hover, .parity1:hover,
|
|
|
|
|
pre.sourcelines.stripes > :nth-child(4n+2):hover,
|
|
|
|
|
pre.sourcelines.stripes > :nth-child(4n+4):hover,
|
|
|
|
|
pre.sourcelines.stripes > :nth-child(4n+1):hover + :nth-child(4n+2),
|
|
|
|
|
pre.sourcelines.stripes > :nth-child(4n+3):hover + :nth-child(4n+4) { background-color:#edece6; }
|
2010-09-26 22:41:32 +04:00
|
|
|
td { padding:2px 5px; font-size:12px; vertical-align:top; }
|
|
|
|
|
td.closed { background-color: #99f; }
|
|
|
|
|
td.link { padding:2px 5px; font-family:sans-serif; font-size:10px; }
|
|
|
|
|
td.indexlinks { white-space: nowrap; }
|
|
|
|
|
td.indexlinks a {
|
|
|
|
|
padding: 2px 5px; line-height: 10px;
|
|
|
|
|
border: 1px solid;
|
|
|
|
|
color: #ffffff; background-color: #7777bb;
|
|
|
|
|
border-color: #aaaadd #333366 #333366 #aaaadd;
|
|
|
|
|
font-weight: bold; text-align: center; text-decoration: none;
|
|
|
|
|
font-size: 10px;
|
|
|
|
|
}
|
|
|
|
|
td.indexlinks a:hover { background-color: #6666aa; }
|
|
|
|
|
div.pre { font-family:monospace; font-size:12px; white-space:pre; }
|
2017-06-09 23:55:51 +03:00
|
|
|
|
|
|
|
|
.search {
|
|
|
|
|
margin-right: 8px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div#hint {
|
|
|
|
|
position: absolute;
|
|
|
|
|
display: none;
|
|
|
|
|
width: 250px;
|
|
|
|
|
padding: 5px;
|
|
|
|
|
background: #ffc;
|
|
|
|
|
border: 1px solid yellow;
|
|
|
|
|
border-radius: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#searchform:hover div#hint { display: block; }
|
|
|
|
|
|
2016-06-02 17:26:50 +03:00
|
|
|
tr.thisrev a { color:#999999; text-decoration: none; }
|
|
|
|
|
tr.thisrev pre { color:#009900; }
|
2016-10-08 13:32:54 +03:00
|
|
|
td.annotate {
|
|
|
|
|
white-space: nowrap;
|
|
|
|
|
}
|
2016-06-28 12:42:42 +03:00
|
|
|
div.annotate-info {
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
z-index: 5;
|
2016-06-28 12:42:42 +03:00
|
|
|
display: none;
|
|
|
|
|
position: absolute;
|
|
|
|
|
background-color: #FFFFFF;
|
2016-07-25 07:33:18 +03:00
|
|
|
border: 1px solid #d9d8d1;
|
2016-06-28 12:42:42 +03:00
|
|
|
text-align: left;
|
|
|
|
|
color: #000000;
|
|
|
|
|
padding: 5px;
|
|
|
|
|
}
|
|
|
|
|
div.annotate-info a { color: #0000FF; text-decoration: underline; }
|
|
|
|
|
td.annotate:hover div.annotate-info { display: inline; }
|
2017-09-30 11:01:36 +03:00
|
|
|
|
|
|
|
|
#diffopts-form {
|
|
|
|
|
padding-left: 8px;
|
|
|
|
|
display: none;
|
|
|
|
|
}
|
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
.linenr { color:#999999; text-decoration:none }
|
|
|
|
|
div.rss_logo { float: right; white-space: nowrap; }
|
|
|
|
|
div.rss_logo a {
|
|
|
|
|
padding:3px 6px; line-height:10px;
|
|
|
|
|
border:1px solid; border-color:#fcc7a5 #7d3302 #3e1a01 #ff954e;
|
|
|
|
|
color:#ffffff; background-color:#ff6600;
|
|
|
|
|
font-weight:bold; font-family:sans-serif; font-size:10px;
|
|
|
|
|
text-align:center; text-decoration:none;
|
|
|
|
|
}
|
|
|
|
|
div.rss_logo a:hover { background-color:#ee5500; }
|
|
|
|
|
pre { margin: 0; }
|
|
|
|
|
span.logtags span {
|
|
|
|
|
padding: 0px 4px;
|
|
|
|
|
font-size: 10px;
|
|
|
|
|
font-weight: normal;
|
|
|
|
|
border: 1px solid;
|
|
|
|
|
background-color: #ffaaff;
|
|
|
|
|
border-color: #ffccff #ff00ee #ff00ee #ffccff;
|
|
|
|
|
}
|
2017-11-16 17:21:03 +03:00
|
|
|
span.logtags span.phasetag {
|
|
|
|
|
background-color: #dfafff;
|
|
|
|
|
border-color: #e2b8ff #ce48ff #ce48ff #e2b8ff;
|
|
|
|
|
}
|
2017-11-18 07:04:08 +03:00
|
|
|
span.logtags span.obsoletetag {
|
|
|
|
|
background-color: #dddddd;
|
|
|
|
|
border-color: #e4e4e4 #a3a3a3 #a3a3a3 #e4e4e4;
|
|
|
|
|
}
|
2017-11-19 09:02:50 +03:00
|
|
|
span.logtags span.instabilitytag {
|
|
|
|
|
background-color: #ffb1c0;
|
|
|
|
|
border-color: #ffbbc8 #ff4476 #ff4476 #ffbbc8;
|
|
|
|
|
}
|
2010-09-26 22:41:32 +04:00
|
|
|
span.logtags span.tagtag {
|
|
|
|
|
background-color: #ffffaa;
|
|
|
|
|
border-color: #ffffcc #ffee00 #ffee00 #ffffcc;
|
|
|
|
|
}
|
|
|
|
|
span.logtags span.branchtag {
|
|
|
|
|
background-color: #aaffaa;
|
|
|
|
|
border-color: #ccffcc #00cc33 #00cc33 #ccffcc;
|
|
|
|
|
}
|
|
|
|
|
span.logtags span.inbranchtag {
|
|
|
|
|
background-color: #d5dde6;
|
|
|
|
|
border-color: #e3ecf4 #9398f4 #9398f4 #e3ecf4;
|
|
|
|
|
}
|
2011-04-03 18:44:28 +04:00
|
|
|
span.logtags span.bookmarktag {
|
|
|
|
|
background-color: #afdffa;
|
|
|
|
|
border-color: #ccecff #46ace6 #46ace6 #ccecff;
|
|
|
|
|
}
|
2015-01-07 02:29:02 +03:00
|
|
|
span.difflineplus { color:#008800; }
|
|
|
|
|
span.difflineminus { color:#cc0000; }
|
|
|
|
|
span.difflineat { color:#990099; }
|
2015-09-21 21:09:10 +03:00
|
|
|
div.diffblocks { counter-reset: lineno; }
|
|
|
|
|
div.diffblock { counter-increment: lineno; }
|
|
|
|
|
pre.sourcelines { position: relative; counter-reset: lineno; }
|
|
|
|
|
pre.sourcelines > span {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
box-sizing: border-box;
|
|
|
|
|
width: 100%;
|
|
|
|
|
padding: 0 0 0 5em;
|
|
|
|
|
counter-increment: lineno;
|
2015-09-24 22:02:38 +03:00
|
|
|
vertical-align: top;
|
2015-09-21 21:09:10 +03:00
|
|
|
}
|
|
|
|
|
pre.sourcelines > span:before {
|
|
|
|
|
-moz-user-select: -moz-none;
|
|
|
|
|
-khtml-user-select: none;
|
|
|
|
|
-webkit-user-select: none;
|
|
|
|
|
-ms-user-select: none;
|
|
|
|
|
user-select: none;
|
|
|
|
|
display: inline-block;
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
margin-left: -6em;
|
2015-09-21 21:09:10 +03:00
|
|
|
width: 4em;
|
|
|
|
|
color: #999;
|
|
|
|
|
text-align: right;
|
|
|
|
|
content: counters(lineno,".");
|
|
|
|
|
float: left;
|
|
|
|
|
}
|
|
|
|
|
pre.sourcelines > a {
|
|
|
|
|
display: inline-block;
|
|
|
|
|
position: absolute;
|
|
|
|
|
left: 0px;
|
|
|
|
|
width: 4em;
|
|
|
|
|
height: 1em;
|
|
|
|
|
}
|
2015-09-25 07:38:20 +03:00
|
|
|
tr:target td,
|
|
|
|
|
pre.sourcelines > span:target,
|
|
|
|
|
pre.sourcelines.stripes > span:target {
|
|
|
|
|
background-color: #bfdfff;
|
|
|
|
|
}
|
2010-09-26 22:41:32 +04:00
|
|
|
|
2017-03-25 05:52:43 +03:00
|
|
|
.description {
|
|
|
|
|
font-family: monospace;
|
2017-07-18 01:54:15 +03:00
|
|
|
white-space: pre;
|
2017-03-25 05:52:43 +03:00
|
|
|
}
|
|
|
|
|
|
2017-04-13 10:49:48 +03:00
|
|
|
/* Followlines */
|
2017-06-21 18:17:17 +03:00
|
|
|
tbody.sourcelines > tr.followlines-selected,
|
2017-04-13 10:49:48 +03:00
|
|
|
pre.sourcelines > span.followlines-selected {
|
|
|
|
|
background-color: #99C7E9 !important;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div#followlines {
|
2017-11-10 13:50:44 +03:00
|
|
|
background-color: #FFF;
|
|
|
|
|
border: 1px solid #d9d8d1;
|
|
|
|
|
padding: 5px;
|
2017-04-13 10:49:48 +03:00
|
|
|
position: fixed;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div.followlines-cancel {
|
|
|
|
|
text-align: right;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div.followlines-cancel > button {
|
|
|
|
|
line-height: 80%;
|
|
|
|
|
padding: 0;
|
|
|
|
|
border: 0;
|
|
|
|
|
border-radius: 2px;
|
|
|
|
|
background-color: inherit;
|
|
|
|
|
font-weight: bold;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div.followlines-cancel > button:hover {
|
|
|
|
|
color: #FFFFFF;
|
|
|
|
|
background-color: #CF1F1F;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
div.followlines-link {
|
|
|
|
|
margin: 2px;
|
|
|
|
|
margin-top: 4px;
|
|
|
|
|
font-family: sans-serif;
|
|
|
|
|
}
|
|
|
|
|
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
.btn-followlines {
|
2017-04-13 10:49:48 +03:00
|
|
|
display: none;
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
cursor: pointer;
|
|
|
|
|
box-sizing: content-box;
|
|
|
|
|
font-size: 11px;
|
|
|
|
|
width: 13px;
|
|
|
|
|
height: 13px;
|
|
|
|
|
border-radius: 3px;
|
|
|
|
|
margin: 0px;
|
|
|
|
|
margin-top: -2px;
|
|
|
|
|
padding: 0px;
|
|
|
|
|
background-color: #E5FDE5;
|
|
|
|
|
border: 1px solid #9BC19B;
|
|
|
|
|
font-family: monospace;
|
|
|
|
|
text-align: center;
|
|
|
|
|
line-height: 5px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
tr .btn-followlines {
|
|
|
|
|
position: absolute;
|
2017-04-13 10:49:48 +03:00
|
|
|
}
|
|
|
|
|
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
span .btn-followlines {
|
|
|
|
|
float: left;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
span.followlines-select .btn-followlines {
|
|
|
|
|
margin-left: -1.6em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.btn-followlines:hover {
|
|
|
|
|
transform: scale(1.1, 1.1);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.btn-followlines .followlines-plus {
|
|
|
|
|
color: green;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.btn-followlines .followlines-minus {
|
|
|
|
|
color: red;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.btn-followlines-end {
|
|
|
|
|
background-color: #ffdcdc;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.sourcelines tr:hover .btn-followlines,
|
|
|
|
|
.sourcelines span.followlines-select:hover > .btn-followlines {
|
2017-04-13 10:49:48 +03:00
|
|
|
display: inline;
|
|
|
|
|
}
|
|
|
|
|
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
.btn-followlines-hidden,
|
|
|
|
|
.sourcelines tr:hover .btn-followlines-hidden {
|
2017-04-13 10:49:48 +03:00
|
|
|
display: none;
|
|
|
|
|
}
|
hgweb: re-implement followlines UI selection using buttons
This changeset attempts to solve two issues with the "followlines" UI in
hgweb. First the "followlines" action is currently not easily discoverable
(one has to hover on a line for some time, wait for the invite message to
appear and then perform some action). Second, it gets in the way of natural
line selection, especially in filerevision view.
This changeset introduces an additional markup element (a <button
class="btn-followlines">) alongside each content line of the view. This button
now holds events for line selection that were previously plugged onto content
lines directly. Consequently, there's no more action on content lines, hence
restoring the "natural line selection" behavior (solving the second problem).
These buttons are hidden by default and get displayed upon hover of content
lines; then upon hover of a button itself, a text inviting followlines section
shows up. This solves the first problem (discoverability) as we now have a
clear visual element indicating that "some action could be perform" (i.e. a
button) and that is self-documented.
In followlines.js, all event listeners are now attached to these <button>
elements. The custom "floating tooltip" element is dropped as <button>
elements are now self-documented through a "title" attribute that changes
depending on preceding actions (selection started or not, in particular).
The new <button> element is inserted in followlines.js script (thus only
visible if JavaScript is activated); it contains a "+" and "-" with a
"diff-semantics" style; upon hover, it scales up.
To find the parent element under which to insert the <button> we either rely
on the "data-selectabletag" attribute (which defines the HTML tag of children
of class="sourcelines" element e.g. <span> for filerevision view and <tr> for
annotate view) or use a child of the latter elements if we find an element
with class="followlines-btn-parent" (useful for annotate view, for which we
have to find the <td> in which to insert the <button>).
On noticeable change in CSS concerns the "margin-left" of span:before
pseudo-elements in filelog view that has been increased a bit in order to
leave space for the new button to appear between line number column and
line content one.
Also note the "z-index" addition for "annotate-info" box so that the latter
appears on top of new buttons (instead of getting hidden).
In some respect, the UI similar to line commenting feature that is implemented
in popular code hosting site like GitHub, BitBucket or Kallithea.
2017-07-03 14:49:03 +03:00
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
/* Graph */
|
|
|
|
|
div#wrapper {
|
|
|
|
|
position: relative;
|
|
|
|
|
margin: 0;
|
|
|
|
|
padding: 0;
|
|
|
|
|
margin-top: 3px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
canvas {
|
|
|
|
|
position: absolute;
|
|
|
|
|
z-index: 5;
|
|
|
|
|
top: -0.9em;
|
|
|
|
|
margin: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ul#nodebgs {
|
|
|
|
|
list-style: none inside none;
|
|
|
|
|
padding: 0;
|
|
|
|
|
margin: 0;
|
|
|
|
|
top: -0.7em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ul#graphnodes li, ul#nodebgs li {
|
|
|
|
|
height: 39px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ul#graphnodes {
|
|
|
|
|
position: absolute;
|
|
|
|
|
z-index: 10;
|
|
|
|
|
top: -0.8em;
|
|
|
|
|
list-style: none inside none;
|
|
|
|
|
padding: 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ul#graphnodes li .info {
|
|
|
|
|
display: block;
|
|
|
|
|
font-size: 100%;
|
|
|
|
|
font-style: italic;
|
|
|
|
|
}
|
2012-07-08 19:17:02 +04:00
|
|
|
|
|
|
|
|
/* Comparison */
|
|
|
|
|
.legend {
|
|
|
|
|
padding: 1.5% 0 1.5% 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.legendinfo {
|
|
|
|
|
border: 1px solid #d9d8d1;
|
|
|
|
|
font-size: 80%;
|
|
|
|
|
text-align: center;
|
|
|
|
|
padding: 0.5%;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.equal {
|
|
|
|
|
background-color: #ffffff;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.delete {
|
2012-07-25 23:49:53 +04:00
|
|
|
background-color: #faa;
|
|
|
|
|
color: #333;
|
2012-07-08 19:17:02 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.insert {
|
2012-07-25 23:49:53 +04:00
|
|
|
background-color: #ffa;
|
2012-07-08 19:17:02 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.replace {
|
2012-07-25 23:49:53 +04:00
|
|
|
background-color: #e8e8e8;
|
2012-07-08 19:17:02 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.comparison {
|
|
|
|
|
overflow-x: auto;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.header th {
|
|
|
|
|
text-align: center;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.block {
|
|
|
|
|
border-top: 1px solid #d9d8d1;
|
|
|
|
|
}
|
2014-01-16 18:23:31 +04:00
|
|
|
|
|
|
|
|
.scroll-loading {
|
|
|
|
|
-webkit-animation: change_color 1s linear 0s infinite alternate;
|
|
|
|
|
-moz-animation: change_color 1s linear 0s infinite alternate;
|
|
|
|
|
-o-animation: change_color 1s linear 0s infinite alternate;
|
|
|
|
|
animation: change_color 1s linear 0s infinite alternate;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@-webkit-keyframes change_color {
|
|
|
|
|
from { background-color: #A0CEFF; } to { }
|
|
|
|
|
}
|
|
|
|
|
@-moz-keyframes change_color {
|
|
|
|
|
from { background-color: #A0CEFF; } to { }
|
|
|
|
|
}
|
|
|
|
|
@-o-keyframes change_color {
|
|
|
|
|
from { background-color: #A0CEFF; } to { }
|
|
|
|
|
}
|
|
|
|
|
@keyframes change_color {
|
|
|
|
|
from { background-color: #A0CEFF; } to { }
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
.scroll-loading-error {
|
|
|
|
|
background-color: #FFCCCC !important;
|
|
|
|
|
}
|
2015-09-04 16:12:07 +03:00
|
|
|
|
|
|
|
|
#doc {
|
|
|
|
|
margin: 0 8px;
|
|
|
|
|
}
|
2010-09-26 22:41:32 +04:00
|
|
|
304 Not Modified
|
|
|
|
|
|
|
|
|
|
|
2014-09-27 16:59:55 +04:00
|
|
|
phase changes are refreshed (issue4061)
|
|
|
|
|
|
|
|
|
|
$ echo bar >> foo
|
|
|
|
|
$ hg ci -msecret --secret
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'log?style=raw'
|
2014-09-27 16:59:55 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# HG changelog
|
|
|
|
|
# Node ID 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
|
|
|
|
|
|
|
|
|
|
changeset: 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
|
|
|
|
|
revision: 0
|
|
|
|
|
user: test
|
|
|
|
|
date: Thu, 01 Jan 1970 00:00:00 +0000
|
|
|
|
|
summary: base
|
|
|
|
|
branch: default
|
|
|
|
|
tag: tip
|
hgweb: allow symbolic revisions with forward slashes in urls
It's possible to have a branch/tag/bookmark with all kinds of special
characters, such as {}/\!?. While not very conveniently, symbolic revisions
with such characters work from command line if user correctly quotes the
characters. These characters also work in hgweb, when they are properly
encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
was getting decoded before hgweb could parse it as a part of PATH_INFO.
Because of that, hgweb was seeing it as any other forward slash, that is, as
just another url parts separator.
For example, if user wanted to see the content of dir/file at bookmark
'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
to find a revision 'feature' and get contents of 'eggs/dir/file'.
To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so
CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision
part of the url into an actual '/' character.
Making hgweb produce such urls will be done in the next 2 patches.
2015-07-12 11:06:57 +03:00
|
|
|
bookmark: @
|
|
|
|
|
bookmark: a b c
|
|
|
|
|
bookmark: d/e/f
|
2014-09-27 16:59:55 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
$ hg phase --draft tip
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'log?style=raw'
|
2014-09-27 16:59:55 +04:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# HG changelog
|
|
|
|
|
# Node ID a084749e708a9c4c0a5b652a2a446322ce290e04
|
|
|
|
|
|
|
|
|
|
changeset: a084749e708a9c4c0a5b652a2a446322ce290e04
|
|
|
|
|
revision: 1
|
|
|
|
|
user: test
|
|
|
|
|
date: Thu, 01 Jan 1970 00:00:00 +0000
|
|
|
|
|
summary: secret
|
|
|
|
|
branch: default
|
|
|
|
|
tag: tip
|
|
|
|
|
|
|
|
|
|
changeset: 2ef0ac749a14e4f57a5a822464a0902c6f7f448f
|
|
|
|
|
revision: 0
|
|
|
|
|
user: test
|
|
|
|
|
date: Thu, 01 Jan 1970 00:00:00 +0000
|
|
|
|
|
summary: base
|
hgweb: allow symbolic revisions with forward slashes in urls
It's possible to have a branch/tag/bookmark with all kinds of special
characters, such as {}/\!?. While not very conveniently, symbolic revisions
with such characters work from command line if user correctly quotes the
characters. These characters also work in hgweb, when they are properly
encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
was getting decoded before hgweb could parse it as a part of PATH_INFO.
Because of that, hgweb was seeing it as any other forward slash, that is, as
just another url parts separator.
For example, if user wanted to see the content of dir/file at bookmark
'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
to find a revision 'feature' and get contents of 'eggs/dir/file'.
To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so
CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision
part of the url into an actual '/' character.
Making hgweb produce such urls will be done in the next 2 patches.
2015-07-12 11:06:57 +03:00
|
|
|
bookmark: @
|
|
|
|
|
bookmark: a b c
|
|
|
|
|
bookmark: d/e/f
|
2014-09-27 16:59:55 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
hgweb: allow symbolic revisions with forward slashes in urls
It's possible to have a branch/tag/bookmark with all kinds of special
characters, such as {}/\!?. While not very conveniently, symbolic revisions
with such characters work from command line if user correctly quotes the
characters. These characters also work in hgweb, when they are properly
encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
was getting decoded before hgweb could parse it as a part of PATH_INFO.
Because of that, hgweb was seeing it as any other forward slash, that is, as
just another url parts separator.
For example, if user wanted to see the content of dir/file at bookmark
'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
to find a revision 'feature' and get contents of 'eggs/dir/file'.
To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so
CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision
part of the url into an actual '/' character.
Making hgweb produce such urls will be done in the next 2 patches.
2015-07-12 11:06:57 +03:00
|
|
|
access bookmarks
|
|
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'rev/@?style=paper' | egrep '^200|changeset 0:'
|
|
|
|
|
200 Script output follows
|
|
|
|
|
changeset 0:<a href="/rev/2ef0ac749a14?style=paper">2ef0ac749a14</a>
|
|
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'rev/%40?style=paper' | egrep '^200|changeset 0:'
|
|
|
|
|
200 Script output follows
|
|
|
|
|
changeset 0:<a href="/rev/2ef0ac749a14?style=paper">2ef0ac749a14</a>
|
|
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'rev/a%20b%20c?style=paper' | egrep '^200|changeset 0:'
|
|
|
|
|
200 Script output follows
|
|
|
|
|
changeset 0:<a href="/rev/2ef0ac749a14?style=paper">2ef0ac749a14</a>
|
|
|
|
|
|
|
|
|
|
$ get-with-headers.py localhost:$HGPORT 'rev/d%252Fe%252Ff?style=paper' | egrep '^200|changeset 0:'
|
|
|
|
|
200 Script output follows
|
|
|
|
|
changeset 0:<a href="/rev/2ef0ac749a14?style=paper">2ef0ac749a14</a>
|
|
|
|
|
|
2015-03-13 15:18:59 +03:00
|
|
|
no style can be loaded from directories other than the specified paths
|
|
|
|
|
|
|
|
|
|
$ mkdir -p x/templates/fallback
|
|
|
|
|
$ cat <<EOF > x/templates/fallback/map
|
|
|
|
|
> default = 'shortlog'
|
|
|
|
|
> shortlog = 'fall back to default\n'
|
|
|
|
|
> mimetype = 'text/plain'
|
|
|
|
|
> EOF
|
|
|
|
|
$ cat <<EOF > x/map
|
|
|
|
|
> default = 'shortlog'
|
|
|
|
|
> shortlog = 'access to outside of templates directory\n'
|
|
|
|
|
> mimetype = 'text/plain'
|
|
|
|
|
> EOF
|
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2015-03-13 15:18:59 +03:00
|
|
|
$ hg serve -p $HGPORT -d --pid-file=hg.pid -A access.log -E errors.log \
|
|
|
|
|
> --config web.style=fallback --config web.templates=x/templates
|
|
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT "?style=`pwd`/x"
|
2015-03-13 15:18:59 +03:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
fall back to default
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT '?style=..'
|
2015-03-13 15:18:59 +03:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
fall back to default
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT '?style=./..'
|
2015-03-13 15:18:59 +03:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
fall back to default
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT '?style=.../.../'
|
2015-03-13 15:18:59 +03:00
|
|
|
200 Script output follows
|
|
|
|
|
|
|
|
|
|
fall back to default
|
|
|
|
|
|
2010-09-26 22:41:32 +04:00
|
|
|
errors
|
|
|
|
|
|
|
|
|
|
$ cat errors.log
|
2012-06-11 03:40:51 +04:00
|
|
|
|
2014-11-28 21:59:02 +03:00
|
|
|
Uncaught exceptions result in a logged error and canned HTTP response
|
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve --config extensions.hgweberror=$TESTDIR/hgweberror.py -p 0 --port-file $TESTTMP/.port -d --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2014-11-28 21:59:02 +03:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
|
|
|
|
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'raiseerror' transfer-encoding content-type
|
2014-11-28 21:59:02 +03:00
|
|
|
500 Internal Server Error
|
|
|
|
|
transfer-encoding: chunked
|
|
|
|
|
|
|
|
|
|
Internal Server Error (no-eol)
|
|
|
|
|
[1]
|
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2014-11-28 21:59:02 +03:00
|
|
|
$ head -1 errors.log
|
|
|
|
|
.* Exception happened during processing request '/raiseerror': (re)
|
|
|
|
|
|
|
|
|
|
Uncaught exception after partial content sent
|
|
|
|
|
|
2018-02-08 02:18:29 +03:00
|
|
|
$ hg serve --config extensions.hgweberror=$TESTDIR/hgweberror.py -p 0 --port-file $TESTTMP/.port -d --pid-file=hg.pid -A access.log -E errors.log
|
|
|
|
|
$ HGPORT=`cat $TESTTMP/.port`
|
2015-01-24 02:47:04 +03:00
|
|
|
$ cat hg.pid >> $DAEMON_PIDS
|
2015-06-08 22:44:30 +03:00
|
|
|
$ get-with-headers.py localhost:$HGPORT 'raiseerror?partialresponse=1' transfer-encoding content-type
|
2014-11-28 21:59:02 +03:00
|
|
|
200 Script output follows
|
|
|
|
|
transfer-encoding: chunked
|
|
|
|
|
content-type: text/plain
|
|
|
|
|
|
|
|
|
|
partial content
|
|
|
|
|
Internal Server Error (no-eol)
|
|
|
|
|
|
2015-06-08 22:55:40 +03:00
|
|
|
$ killdaemons.py
|
2012-06-11 03:40:51 +04:00
|
|
|
$ cd ..
|
