Skip to content
Snippets Groups Projects
  1. Sep 27, 2010
  2. Sep 20, 2010
    • Ry4an Brase's avatar
      Correct Content-Type header values for archive downloads. · a72c5ff1
      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.
      a72c5ff1
  3. Sep 26, 2010
  4. Sep 24, 2010
  5. Sep 21, 2010
  6. Sep 27, 2010
  7. Sep 24, 2010
  8. Sep 23, 2010
  9. Sep 22, 2010
  10. Sep 21, 2010
  11. Sep 20, 2010
  12. Sep 17, 2010
  13. Sep 20, 2010
    • Martin Geisler's avatar
      archive: set date to 1980 for very old zip files · 381f1312
      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.
      381f1312
  14. Sep 17, 2010
    • Steve Borho's avatar
      test-eol-update: record new results as correct · ed639917
      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.
      ed639917
  15. Sep 16, 2010
  16. Sep 15, 2010
    • Steve Borho's avatar
      eol: setup the repo.ui in reposetup() · 0852da25
      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.
      0852da25
  17. Sep 14, 2010
  18. Sep 11, 2010
  19. Sep 13, 2010
  20. Sep 10, 2010
    • Brodie Rao's avatar
      convert/darcs: handle non-ASCII metadata in darcs changelog (issue2354) · 4481f8a9
      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.)
      4481f8a9
Loading