Skip to content
Snippets Groups Projects
  1. Jun 29, 2011
  2. Jun 16, 2011
  3. May 30, 2011
  4. May 13, 2011
  5. May 09, 2011
  6. May 01, 2011
  7. Apr 17, 2011
  8. Apr 20, 2011
    • Steven Stallion's avatar
      hgweb: support disabling page cache · a1c31c64
      Steven Stallion authored
      By default, hgweb_mod supports caching via the ETag header. This can
      cause some confusion with browsers which cache aggressively. This change
      preserves existing behavior while giving the administrator a knob to
      disable the ETag header.
      a1c31c64
    • Steven Stallion's avatar
      hgweb: support alternate logo url · 616ad3f6
      Steven Stallion authored
      Clicking on the logo image/text in the hgweb interface brings the
      user to the Mercurial project page. The majority of users expect that
      this would bring them to the top level index. I have added a new template
      variable named `logourl' which allows an administrator to change this
      behavior. To stay compatible with existing behavior, `logourl' will
      default to http://mercurial.selenic.com/. This change is very useful in
      large installations where jumping to the index is common.
      616ad3f6
  9. Apr 19, 2011
    • Adrian Buehlmann's avatar
      add: introduce a warning message for non-portable filenames (issue2756) (BC) · 8b252e82
      Adrian Buehlmann authored
      On POSIX platforms, the 'add', 'addremove', 'copy' and 'rename' commands now
      warn if a file has a name that can't be checked out on Windows.
      
      Example:
      
        $ hg add con.xml
        warning: filename contains 'con', which is reserved on Windows: 'con.xml'
        $ hg status
        A con.xml
      
      The file is added despite the warning.
      
      The warning is ON by default. It can be suppressed by setting the config option
      'portablefilenames' in section 'ui' to 'ignore' or 'false':
      
        $ hg --config ui.portablefilenames=ignore add con.xml
        $ hg sta
        A con.xml
      
      If ui.portablefilenames is set to 'abort', then the command is aborted:
      
        $ hg --config ui.portablefilenames=abort add con.xml
        abort: filename contains 'con', which is reserved on Windows: 'con.xml'
      
      On Windows, the ui.portablefilenames config setting is irrelevant and the
      command is always aborted if a problematic filename is found.
      8b252e82
  10. Apr 07, 2011
  11. Mar 24, 2011
    • Patrick Mezard's avatar
      patch: deprecate ui.patch / external patcher feature · 85d74f6b
      Patrick Mezard authored
      Why?
      - Mercurial internal patcher works correctly for regular patches and git
        patches, is much faster at least on Windows and is more extensible.
      - In theory, the external patcher can be used to handle exotic patch formats. I
        do not know any and have not heard about any such use in years.
      - Most patch programs cannot handle git format patches, which makes the API
        caller to decide either to ignore ui.patch by calling patch.internalpatch()
        directly, or take the risk of random failures with valid inputs.
      - One thing a patch program could do Mercurial patcher cannot is applying with
        --reverse. Apparently several shelve like extensions try to use that,
        including passing the "reverse" option to Mercurial patcher, which has been
        removed mid-2009. I never heard anybody complain about that, and would prefer
        reimplementing it anyway.
      
      And from the technical perspective:
      - The external patcher makes everything harder to maintain and implement. EOL
        normalization is not implemented, and I would bet file renames, if supported
        by the patcher, are not correctly recorded in the dirstate.
      - No tests.
      
      How?
      - Remove related documentation
      - Clearly mark patch.externalpatch() as private
      - Remove the debuginstall check. This deprecation request was actually
        triggered by this last point. debuginstall is the only piece of code patching
        without a repository. When migrating to an integrated patch() + updatedir()
        call, this was really a showstopper, all workarounds were either ugly or
        uselessly complicated to implement. If we do not support external patcher
        anymore, the debuginstall check is not useful anymore.
      - Remove patch.externalpatch() after 1.9 release.
      85d74f6b
  12. Mar 08, 2011
  13. Feb 15, 2011
    • Patrick Mezard's avatar
      commit: abort if a subrepo is modified and ui.commitsubrepos=no · d4de90a6
      Patrick Mezard authored
      The default behaviour is to commit subrepositories with uncommitted changes. In
      my experience this is usually undesirable:
      
      - Changes to dependencies are often debugging leftovers
      - Real changes should generally be applied on the source project directly,
        tested then committed. This is not always possible, subversion subrepos may
        include only a small part of the source project, without the tests.
      
      Setting ui.commitsubrepos=no will now abort commits containing such modified
      subrepositories like:
      
        $ hg --config ui.commitsubrepos=no ci -m msg
        abort: uncommitted changes in subrepo sub
      
      I ruled out the hook solution because it does not easily take --include/exclude
      options in account. Also, my main concern is whether this flag could cause
      problems with extensions. If there are legitimate reasons for callers to
      override this behaviour (I could not find any), they might either override at ui
      level, or we could add an argument to localrepo.commit() later.
      
      v2:
      - Renamed ui.commitsubs to ui.commitsubrepos
      - Mention the configuration entry in hg help subrepos
      d4de90a6
  14. Feb 11, 2011
  15. Feb 05, 2011
  16. Feb 01, 2011
  17. Jan 29, 2011
  18. Jan 28, 2011
  19. Jan 05, 2011
  20. Dec 20, 2010
    • Zhigang Wang's avatar
      smtp: fix for server doesn't support starttls extension · f0525057
      Zhigang Wang authored
      
      Currently we only support enabling TLS by using SMTP STARTTLS extension. But
      not all the servers support it.
      
      With this patch, user can choose which way to enable TLS:
      
      * Default:
      
            tls = none
            port = 25
      
      * To use STARTTLS:
      
            tls = starttls
            port = 465
      
      * To use SMTP over SSL:
      
            tls = smtps
            port = 465
      
      To keep backward compatibility, when tls = true, we use STARTTLS to enable TLS.
      
      Signed-off-by: default avatarZhigang Wang <w1z2g3@gmail.com>
      f0525057
  21. Dec 03, 2010
  22. Dec 01, 2010
  23. Nov 04, 2010
  24. Oct 26, 2010
  25. Oct 23, 2010
  26. Oct 24, 2010
Loading