tests/test-flags

Fix inconsistency for the stream_out capability in hgweb

During some experiments of mine, the uncompressed cloning could not
be enabled for hgweb.cgi nor hgwebdir.cgi though the server claimed
to be stream_out capable.

The only solution was to enable it using the user's .hgrc file.
This solution is not acceptable when publishing the repos through
an HTTP server because the CGI runs as a www dedicated user whose's
home hgrc file may not be accessible to users publishing their repos
through their userdir.

For such cases we could end up with this typical debug output:
hg --debug clone --uncompressed http://server/hg/project
destination directory: project
sending capabilities command
capabilities: lookup changegroupsubset stream=1
unbundle=HG10GZ,HG10BZ,HG10UN
sending stream_out command
abort: operation forbidden by server

The error lies in the fact the hgweb object defines new accessors
to the repo configuration that trust things by default (untrusted=True)
but the streamclone:stream_out function uses the usual accessors to the
repo.ui object, which do not trust by default (untrusted=False)

Fix this inconsistency, adding a new parameter to the stream_out function.
hgweb then forces a "trust by default" behavior.

#!/bin/sh -e

umask 027
mkdir test1
cd test1

hg init
touch a b
hg add a b
hg ci -m "added a b" -d "1000000 0"

cd ..
hg clone test1 test3
mkdir test2
cd test2

hg init
hg pull ../test1
hg co
chmod +x a
hg ci -m "chmod +x a" -d "1000000 0"
echo % the changelog should mention file a:
hg tip --template '#files#\n'

cd ../test1
echo 123 >>a
hg ci -m "a updated" -d "1000000 0"

hg pull ../test2
hg heads
hg history

hg -v merge

cd ../test3
echo 123 >>b
hg ci -m "b updated" -d "1000000 0"

hg pull ../test2
hg heads
hg history

hg -v merge

ls -l ../test[123]/a > foo
cut -b 1-10 < foo

hg debugindex .hg/store/data/a.i
hg debugindex ../test2/.hg/store/data/a.i
hg debugindex ../test1/.hg/store/data/a.i