The content type for both .tar.gz and .tar.bz2 downloads was
application/x-tar, which is correct for .tar files when no
Content-Encoding is present, but is not correct for .tar.gz and .tar.bz2
files unless Content-Encoding is set to gzip or x-bzip2, respectively.
However, setting Content-Encoding causes browsers to undo that encoding
during download, when a .gz or .bz2 file is usually the desired
artifact. Omitting the Content-Encoding header is preferred to avoid
having browsers uncompress non-render-able files.
Additionally, the Content-Disposition line indicates a final desired
filename with .tar.gz or .tar.bz2 extension which makes providing a
Content-Encoding header inappropriate.
With the current configuration browsers (Chrome and Firefox thus far)
are registering the application/x-tar Content-Type and not .tar
extension and appending that extension, yielding filename.tar.gz.tar as
a final on-disk artifact. This was originally reported here:
http://stackoverflow.com/questions/3753659
I've changed the .tar.gz and .tar.bz2 Content-Type values to
application/x-gzip and application/x-bzip2, respectively. Which yields
correctly named download artifacts on Firefox, Chrome, and IE.
The coal and paper web themes will highlight closed branches as a visual cue to
the user. This patch makes the other two themes constistent.
For users with difficulty differentiating colors, it would be better to split
out closed branches to a new table or optionally hide them.
Changeset 1e63d4dee4f6 deprecated qsave and qrestore. In the
deprecating comment, users were referred to 'rebase --mq' which -- at
the time the message was written -- didn't exist. Currently, on the
default branch, rebase *does* take a '--mq' option, but it probably
doesn't do what Dirkjan expected it to do when he wrote the message.
In the original, deprecating commit, little context was provided as to
why this change was made. Based on my recollection, concensus at the
Paris Sprint in February 2010 was that one of the problems with MQ was
that it exposed far too many commands. Notable among these were qsave
& qrestore: very few core developers understood what they did and even
fewer (none, IIRC) actually used them. However, they couldn't be
removed; not only do the usual backwards compatibility reasons apply,
but the hg book refers to them.
Changeset 63043d17c14b changed the result of this test. The 'hg update 0'
command, which causes a merge of modified a.txt, now leaves a.txt in the
EOLN format specified by .hgeol as it was committed in revision 0.
Previously, it used the .hgeol contents from the working directory before the
update.
The zip file format stores the date using "MS-DOS format" which
apparently means that they use 1980 as their epoch. Python's zipfile
module emits deprecation warnings of this form
/usr/lib/python2.6/zipfile.py:1108: DeprecationWarning: struct
integer overflow masking is deprecated
self.fp.write(zinfo.FileHeader())
/usr/lib/python2.6/zipfile.py:1108: DeprecationWarning: 'H' format
requires 0 <= number <= 65535
self.fp.write(zinfo.FileHeader())
/home/mg/src/mercurial-crew/mercurial/archival.py:169:
DeprecationWarning: struct integer overflow masking is deprecated
self.z.close()
/home/mg/src/mercurial-crew/mercurial/archival.py:169:
DeprecationWarning: 'H' format requires 0 <= number <= 65535
self.z.close()
when it is given such old timestamps. This fixes this by silently
clamping the date to 1980.
This fixes problems some have reported using the eol extension
together with TortoiseHg. It ensures the ui associated with the
repository has the preupdate.eol hook configured.
This complicates the code a bit, since attributes need to be masked together
correctly before they are applied. Perhaps the code should be redesigned at
some point, but this works well for now.
Without specifying the parent revision of the working copy, users will
update to tip, which is most likely the other head they were trying to
merge, not the revision they were at before the merge.
As stated in http://msdn.microsoft.com/en-us/library/cc664727.aspx, when you
compile an application with MSVC 2008 SP1 it is bound by default to the
original CRT version (9.0.21022.8). This is the case for Python 2.6 up to 3.1.
If the wrong CRT version is embedded in the Inno Setup installer, with a PC
that does not have the MSVC 2008 redistributable package installed, hg will
refuse to launch with an error: "the system cannot execute the specified
program".
This patch fixes issues with stream cloning in the presense of parentdelta,
lwcopy and similar additions that change the interpretation of the revlog
format, or the format itself.
Currently, the stream capability is sent like this:
stream=<version of changelog>
But the client doesn't actually check the version number; also, it only checks
the changelog and it doesn't capture the interpretation-changes and
flag-changes in parentdelta and lwcopy.
This patch removes the 'stream' capability whenever we use a non-basic revlog
format, to prevent old clients from receiving incorrect data. In those cases,
a new capability called 'streamreqs' is added instead. Instead of a revlog
version, it comes with a list of revlog-format relevant requirements, which
are a subset of the repository requirements, excluding things that are not
relevant for stream.
New clients use this to determine whether or not they can stream. Old clients
only look for the 'stream' capability, as always. New servers will still send
this when serving old repositories.
