- Sep 27, 2010
-
-
Patrick Mezard authored
-
Matt Mackall authored
-
- Sep 20, 2010
-
-
Ry4an Brase authored
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.
-
- Sep 26, 2010
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Sep 24, 2010
-
-
Wagner Bruna authored
-
Wagner Bruna authored
-
- Sep 21, 2010
-
-
Wagner Bruna authored
-
- Sep 27, 2010
-
-
Erik Zielke authored
The -m option became deprecated in changeset bcf90e712dc3, but the option still appeared in the help line for the qpush command
-
- Sep 24, 2010
-
-
kiilerix authored
Solaris had problems with zh_CN and warned "couldn't set locale correctly" on stderr. We don't care.
-
kiilerix authored
It seems like ln -s gets confused if an existing symlink is dangling: $ rm -f a b; ln -s a b; ln -sf b b ln: cannot create b: File exists We now rely on rm instead of on ln -sf.
-
kiilerix authored
Backport 3acd5f7ab9d0 and 9581d5efb6a5 to stable.
-
- Sep 23, 2010
-
-
Patrick Mezard authored
-
Patrick Mezard authored
_bookmarks is loaded lazily and calls super.lookup(). Unfortunately, branch and tags caches initializations also recurse in lookup() and end up trying to access _bookmarks again. Massive confusion ensues. I considered fixing all branches and tags cache loading to avoid recursing in lookup() but it would add complexity to otherwise working code provided lookups are performed on nodes or revnums.
-
Alexandre Fayolle authored
When using hg commands over an http repository in a long running process, a httphandler instance is leaked for each command, because of a loop handler.parent -> OpenerDirector and OpenerDirector.handlers -> handler which is not handled by Python's gc. Discussion on #mercurial concluded that removing the __del__ method solved the problem.
-
Brodie Rao authored
-
Anthony Foiani authored
-
- Sep 22, 2010
-
-
kiilerix authored
f786fc4b8764 assumed that walkchangerevs called prep with all relevant matched filenames, but actually it only contains the names of files changed in the relevant changeset. That meant that log diff/stat of merges missed the diff for files only changed in the other branch. This is a minimal fix for making sure we only use fns when we are following and thus will have problems with merges anyway ...
-
kiilerix authored
01-01-1980 slipped through the grep.
-
Matt Mackall authored
-
Patrick Mezard authored
--force was not necessary when passing --rev since 55578a8d7e84, but this behaviour is usually harmful when branch names are passed instead of explicit revisions.
-
- Sep 21, 2010
-
-
Patrick Mezard authored
-
- Sep 20, 2010
-
-
Matt Mackall authored
-
Ryan Phillips authored
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.
-
Dan Villiom Podlaski Christiansen authored
Changeset bcf90e712dc3 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.
-
Patrick Mezard authored
-
Patrick Mezard authored
-
Patrick Mezard authored
-
Patrick Mezard authored
-
Patrick Mezard authored
-
- Sep 17, 2010
-
-
Brodie Rao authored
Raise error.ParseError instead of allowing re.error to bubble up.
-
- Sep 20, 2010
-
-
Martin Geisler authored
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.
-
- Sep 17, 2010
-
-
Steve Borho authored
Changeset 0852da25a31b 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.
-
- Sep 16, 2010
-
-
Matt Mackall authored
-
- Sep 15, 2010
-
-
Steve Borho authored
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.
-
- Sep 14, 2010
-
-
Matt Mackall authored
-
- Sep 11, 2010
-
-
Wagner Bruna authored
-
- Sep 13, 2010
-
-
Sune Foldager authored
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.
-
- Sep 10, 2010
-
-
Brodie Rao authored
Given a commit author or message with non-ASCII characters in a darcs repo, convert would raise a UnicodeEncodeError when adding changesets to the hg changelog. This happened because etree returns back unicode objects for any text it can't encode into ASCII. convert was passing these objects to changelog.add(), which would then attempt encoding.fromlocal() on them. This patch ensures converter_source.recode() is called on each piece of commit data returned by etree. (Also note that darcs is currently encoding agnostic and will print out whatever is in a patch's metadata byte-for-byte, even in the XML changelog.)
-