Skip to content
Snippets Groups Projects
  1. Jul 14, 2015
    • Katsunori FUJIWARA's avatar
      record: omit meaningless 'commit' suggestion at 'hg commit -i' · 4eb8d8a4
      Katsunori FUJIWARA authored
      Before this patch, 'hg commit -i' under non-interactive mode suggests
      'use commit instead', and it obviously meaningless.
      
      This patch makes 'record.record'()' examine 'ui.interactive()' and
      show suggestion by itself before calling 'commands.commit()'.
      
      This allows 'commands.commit()' to specify 'None' for 'cmdsuggest'
      argument of 'cmdutil.dorecord()' to omit meaningless 'commit'
      suggestion at 'hg commit -i'.
      4eb8d8a4
    • Katsunori FUJIWARA's avatar
      cmdutil: allow callers of cmdutil.dorecord to omit suggestion · 69145daa
      Katsunori FUJIWARA authored
      Interactive committing under non-interactive mode shows command
      suggestion, but sometimes it is meaningless.
      
        command      suggestion usability
        ------------ ---------- -----------
        record       commit
        commit -i    commit     meaningless
        qrecord      qnew
        qnew -i      qnew       meaningless
        qrefersh -i  qrefresh   meaningless
        shelve -i    commit     incorrect
        ------------ ---------- -----------
      
      This patch allows callers of 'cmdutil.dorecord()' to omit meaningless
      suggestion by passing None or so for 'cmdsuggest' argument of it.
      
      This is a preparation for subsequent patches, which fix each
      suggestion issues above.
      69145daa
  2. Jul 11, 2015
  3. Jun 25, 2015
    • Matt Mackall's avatar
      hgk: tweak doc format for path option · 08495766
      Matt Mackall authored
      This lets the config checker see it.
      08495766
    • Matt Mackall's avatar
      acl: mark deprecated config option · dd166d42
      Matt Mackall authored
      This option has been undocumented since day 0.
      dd166d42
    • Matt Mackall's avatar
      gpg: mention undocumented options · 917be057
      Matt Mackall authored
      917be057
    • Matt Mackall's avatar
      check-config: add config option checker · db5b6a1c
      Matt Mackall authored
      This script scans files for lines that look like either ui.config
      usage or config variable documentation. It then ensures:
      
      - ui.config calls for each option agree on types and defaults
      - every option appears to be mentioned in documentation
      
      It doesn't complain about devel/experimental options and allows
      marking options that are not intended to be public.
      
      Since we haven't been able to come up with a good scheme for
      documenting config options at point of use, this will help close the
      loop of making sure all options that should be documented are.
      db5b6a1c
  4. Jul 14, 2015
  5. Jul 12, 2015
  6. Jun 20, 2015
  7. Jun 21, 2015
  8. Jun 15, 2015
  9. Jul 12, 2015
    • Anton Shestakov's avatar
      hgweb: provide links to branches, tags and bookmarks by name (paper and coal) · cd842821
      Anton Shestakov authored
      It's sometimes handy to, say, have a url always point to branch head, not just
      at the current branch head by node hash. Previously, this was only possible by
      manually editing url and replacing node hash with branch/tag/bookmark name. It
      wasn't very convenient, or easy - in case the name contained special
      characters that needed to be urlencoded.
      
      Let's have /branches, /tags and /bookmarks pages in paper and coal style
      provide links both to symbolic revisions and to node hashes.
      
      This feature was wished for in issue3594.
      cd842821
    • Anton Shestakov's avatar
      templates: introduce revescape filter for escaping symbolic revisions · 3a334127
      Anton Shestakov authored
      There needs to be a way to escape symbolic revisions containing forward
      slashes, but urlescape filter doesn't escape slashes at all (in fact, it is
      used in places where forward slashes must be preserved).
      
      The filter considers @ to be safe just for bookmarks like @ and @default to
      look good in urls.
      3a334127
    • Anton Shestakov's avatar
      hgweb: allow symbolic revisions with forward slashes in urls · 1c2a8db3
      Anton Shestakov authored
      It's possible to have a branch/tag/bookmark with all kinds of special
      characters, such as {}/\!?. While not very conveniently, symbolic revisions
      with such characters work from command line if user correctly quotes the
      characters. These characters also work in hgweb, when they are properly
      encoded, with one exception: '/' (forward slash, urlencoded as '%2F'), which
      was getting decoded before hgweb could parse it as a part of PATH_INFO.
      Because of that, hgweb was seeing it as any other forward slash, that is, as
      just another url parts separator.
      
      For example, if user wanted to see the content of dir/file at bookmark
      'feature/eggs', url could be: '/file/feature%2Feggs/dir/file'. But hgweb tried
      to find a revision 'feature' and get contents of 'eggs/dir/file'.
      
      To fix this, let's assume forward slashes are doubly-urlencoded (%252F), so
      CGI/WSGI server decodes it into %2F. Then we can decode %2F in the revision
      part of the url into an actual '/' character.
      
      Making hgweb produce such urls will be done in the next 2 patches.
      1c2a8db3
  10. Jul 13, 2015
  11. Jul 08, 2015
    • Eugene Baranov's avatar
      convert: if getting a file from Perforce fails try to get it one more time · 220d9ae6
      Eugene Baranov authored
      When converting a particularly large Perforce changelist (especially with  some
      big files), it is very likely to run into an intermittent network issue (e.g.
      WSAECONNRESET or WSAETIMEDOUT) getting one of the files, which will result in
      the entire changelist converting being aborted. Which can be quite unfortunate
      since you might have waited hours getting all other files. To mitigate this
      let's attempt to get the file one more time, escalating original exception
      if that attempt fails.
      220d9ae6
  12. Jul 13, 2015
    • Katsunori FUJIWARA's avatar
      shelve: keep old backups if timestamp can't decide exact order of them · 4f8c20fe
      Katsunori FUJIWARA authored
      Before this patch, backups to be discarded are decided by steps below
      at 'hg unshelve' or so:
      
        1. list '(st_mtime, filename)' tuples of each backups up
        2. sort list of these tuples, and
        3. discard backups other than 'maxbackups' ones at the end of list
      
      This doesn't work well in the case below:
      
        - "sort by name" order differs from actual backup-ing order, and
        - some of backups have same timestamp
      
      For example, 'test-shelve.t' satisfies the former condition:
      
        - 'default-01' < 'default-1' in "sort by name" order
        - 'default-1'  < 'default-01' in actual backup-ing order
      
      Then, 'default-01' is discarded instead of 'default-1' unexpectedly,
      if they have same timestamp. This failure appears occasionally,
      because the most important condition "same timestamp" is timing
      critical.
      
      To avoid such unexpected discarding, this patch keeps old backups if
      timestamp can't decide exact order of them.
      
      Timestamp of the border backup (= the oldest one of recent
      'maxbackups' ones) as 'bordermtime' is used to examine whether
      timestamp can decide exact order of backups.
      4f8c20fe
  13. Jul 09, 2015
  14. Jul 02, 2015
  15. Jun 28, 2015
  16. Mar 16, 2015
    • Yuya Nishihara's avatar
      revset: use integer representation of wdir() in revset · 5e1b0739
      Yuya Nishihara authored
      This is the simplest way to handle wdir() revision in revset. None didn't
      work well because revset heavily depends on integer operations such as min(),
      max(), sorted(), x:y, etc.
      
      One downside is that we cannot do "wctx.rev() in set" because wctx.rev() is
      still None. We could wrap the result set by wdirproxyset that translates None
      to wdirrev, but it seems overengineered at this point.
      
          result = getset(repo, subset, tree)
          if 'wdir' in funcsused(tree):
              result = wdirproxyset(result)
      
      Test cases need the '(all() + wdir()) &' hack because we have yet to fix the
      bootstrapping issue of null and wdir.
      5e1b0739
  17. Aug 16, 2014
    • Yuya Nishihara's avatar
      localrepo: provide workingctx by integer revision · 22049b56
      Yuya Nishihara authored
      This allows us to use the integer representation in revset. None doesn't
      work well while computing revset because revset heavily depends on and
      optimized for integer revisions.
      
      Still repo[wdirrev].rev() is None, which means the canonical form of the
      working-directory revision is None.
      
      This patch doesn't add the case for the wdirid because we can't handle short
      and ambiguous identifiers here. Perhaps, the wdirid will have to be handled
      in the changelog layer.
      22049b56
  18. Apr 12, 2015
    • Yuya Nishihara's avatar
      changeset_printer: change flush() to accept ctx instead of rev · 60c79159
      Yuya Nishihara authored
      Because flush() is the function to write data buffered by show(ctx),
      flush(ctx) is more consistent than flush(rev). This makes sure that
      buffered header and hunk are always keyed by ctx.rev().
      
      This patch will allow us to give an integer to the wdir while keeping
      wctx.rev() -> None.
      60c79159
  19. Jul 04, 2015
  20. Jul 08, 2015
    • Gregory Szorc's avatar
      hg: support for auto sharing stores when cloning · 0d37b9b2
      Gregory Szorc authored
      Many 3rd party consumers of Mercurial have created wrappers to
      essentially perform clone+share as a single operation. This is
      especially popular in automated processes like continuous integration
      systems. The Jenkins CI software and Mozilla's Firefox release
      automation infrastructure have both implemented custom code that
      effectively perform clone+share. The common use case here is that
      clients want to obtain N>1 checkouts while minimizing disk space and
      network requirements. Furthermore, they often don't care that a clone
      is an exact mirror of a remote: they are simply looking to obtain
      checkouts of specific revisions.
      
      When multiple third parties implement a similar feature, it's a good
      sign that the feature is worth adding to the core product. This patch
      adds support for an easy-to-use clone+share feature.
      
      The internal "clone" function now accepts options to control auto
      sharing during clone. When the auto share mode is active, a store will
      be created/updated under the base directory specified and a new
      repository pointing to the shared store will be created at the path
      specified by the user.
      
      The share extension has grown the ability to pass these options into
      the clone command/function.
      
      No command line options for this feature are added because we don't
      feel the feature will be popular enough to warrant their existence.
      
      There are two modes for auto share mode. In the default mode, the shared
      repo is derived from the first changeset (rev 0) in the remote
      repository. This enables related repositories existing at different URLs
      to automatically use the same storage. In environments that operate
      several repositories (separate repo for branch/head/bookmark or separate
      repo per user), this has the potential to drastically reduce storage
      and network requirements. In the other mode, the name is derived from the
      remote's path/URL.
      0d37b9b2
    • Matt Mackall's avatar
      merge with stable · 648323f4
      Matt Mackall authored
      648323f4
    • Katsunori FUJIWARA's avatar
      cmdutil: apply dirstate.normallookup on (maybe partially) committed files · ff11c156
      Katsunori FUJIWARA authored
      To detect change of a file without redundant comparison of file
      content, dirstate recognizes a file as certainly clean, if:
      
        (1) it is already known as "normal",
        (2) dirstate entry for it has valid (= not "-1") timestamp, and
        (3) mode, size and timestamp of it on the filesystem are as same as
            ones expected in dirstate
      
      This works as expected in many cases, but doesn't in the corner case
      that changing a file keeps mode, size and timestamp of it on the
      filesystem.
      
      The timetable below shows steps in one of typical such situations:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              ***   ***
             - change "f"                                     N
      
             - execute 'hg commit -i'
               - backup "f" with timestamp N
               - revert "f" by 'merge.update()'               N
                 with 'partially'
               - apply selected hunks                         N
                 by 'patch.patch()'
      
               - 'repo.commit()'
                 - 'dirstate.normal("f")'         N
        N+1
                 - 'dirstate.write()'             N    N
      
               - restore "f"                                  N+1
               - restore timestamp of "f"                     N
      
             - 'hg status' shows "f" as "clean"   N    N      N
        ---- ----------------------------------- ---- ----- -----
      
      The most important point is that 'dirstate.write()' is executed at N+1
      or later. This causes writing dirstate timestamp N of "f" out
      successfully. If it is executed at N, 'parsers.pack_dirstate()'
      replaces timestamp N with "-1" before actual writing dirstate out.
      
      This issue can occur when 'hg commit -i' satisfies conditions below:
      
        - the file is committed partially, and
        - mode and size of the file aren't changed before and after committing
      
      The root cause of this issue is that (maybe partially changed) files
      are restored with original timestamp but dirstate isn't updated for
      them.
      
      To detect changes of files correctly, this patch applies
      'dirstate.normallookup()' on restored files. Status check is needed
      before 'dirstate.normallookup()', because status other than "n(ormal)"
      should be kept at failure of committing.
      
      This patch doesn't examine whether each files are committed fully or
      partially, because interactive hunk selection makes it difficult.
      
      After this change, timetable is changed as below:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              ***   ***
             - change "f"                                     N
      
             - execute 'hg commit -i'
               - backup "f" with timestamp N
               - revert "f" by 'merge.update()'               N
                 with 'partially'
               - apply selected hunks                         N
                 by 'patch.internalpatch()'
      
               - 'repo.commit()'
                 - 'dirstate.normal("f")'         N
        N+1
                 - 'dirstate.write()'             N    N
      
               - restore "f"                                  N+1
               - restore timestamp of "f"                     N
             ----------------------------------- ---- ----- -----
               - normallookup("f")                -1
               - release wlock
                 - 'dirstate.write()'             -1   -1     N
             ----------------------------------- ---- ----- -----
      
             - 'hg status' shows "f" as "clean"   -1   -1     N
        ---- ----------------------------------- ---- ----- -----
      
      To reproduce this issue in tests certainly, this patch emulates some
      timing critical actions as below:
      
        - change "f" at N
      
          'touch -t 200001010000' before command invocation changes mtime of
          "f" to "2000-01-01 00:00" (= N).
      
        - apply selected hunks at N
      
          'patch.internalpatch()' with 'fakepatchtime.py' explicitly changes
          mtime of patched files to "2000-01-01 00:00" (= N).
      
        - 'dirstate.write()' at N+1 (or "not at N")
      
          'pack_dirstate()' uses actual timestamp at runtime as "now", and
          it should be different from the "2000-01-01 00:00" of "f".
      
      BTW, in 'test-commit-interactive.t', files are sometimes treated as
      modified , even though they are just committed fully via 'hg commit
      -i' and 'hg diff' shows nothing for them.
      
      Enabling win32text causes EOL style mismatching below:
      
        - files are changed in LF style EOL
      
          => files restored after committing uses LF style EOL (1)
      
        - 'merge.update()' reverts files in CRLF style EOL
        - 'patch.internalpatch()' changes files in CRLF style EOL
      
          => 'dirstate.normal()' via 'repo.commit()' uses the size of files
             in CRLF style EOL (2)
      
      Therefore, fully committed files are treated as "modified", because
      'lstat()' returns size of (1) restored files in LF style EOL, but
      dirstate expects size of (2) committed files in CRLF style EOL.
      
      After this patch, 'dirstate.normallookup()' on committed files forces
      subsequent 'hg status' to examine changes exactly, and fully committed
      files are treated as clean as expected.
      
      This is reason why this patch also does:
      
        - add some 'hg status' checking status of fully committed files
        - clear win32text configuration before size/timestamp sensitive examination
      ff11c156
    • Katsunori FUJIWARA's avatar
      cmdutil: put recordfunc invocation into wlock scope for consistency · c5dfa47a
      Katsunori FUJIWARA authored
      Before this patch, 'recordfunc()' for interactive hunk selection does
      below outside wlock scope at 'hg commit -i' and so on:
      
        - backup files, which may be partially changed
        - apply selected hunks on files
        - restore files from backup-ed ones
      
      These should be executed inside wlock scope for consistency.
      
      To put them into wlock scope without largely changing indents in
      'recordfunc()', this patch adds another wrapper function.
      
      This patch is also a preparation for subsequent patch fixing the issue
      to correctly recognize partially committed files as "modified".
      c5dfa47a
    • Katsunori FUJIWARA's avatar
      context: write dirstate out explicitly at the end of markcommitted · 4d1382fd
      Katsunori FUJIWARA authored
      To detect change of a file without redundant comparison of file
      content, dirstate recognizes a file as certainly clean, if:
      
        (1) it is already known as "normal",
        (2) dirstate entry for it has valid (= not "-1") timestamp, and
        (3) mode, size and timestamp of it on the filesystem are as same as
            ones expected in dirstate
      
      This works as expected in many cases, but doesn't in the corner case
      that changing a file keeps mode, size and timestamp of it on the
      filesystem.
      
      The timetable below shows steps in one of typical such situations:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
         *                                             ***    ***
             - 'hg transplant REV1 REV2 ...'
               - transplanting REV1
                 ....
         N
                 - change "f", but keep size                   N
                   (via 'patch.patch()')
                 - 'dirstate.normal("f")'          N   ***
                   (via 'repo.commit()')
      
               - transplanting REV2
                 - change "f", but keep size                   N
                   (via 'patch.patch()')
                 - aborted while patching
        N+1
               - release wlock
                 - 'dirstate.write()'              N    N      N
      
             - 'hg status' shows "r1" as "clean"   N    N      N
        ---- ----------------------------------- ---- ----- -----
      
      The most important point is that 'dirstate.write()' is executed at N+1
      or later. This causes writing dirstate timestamp N of "f" out
      successfully. If it is executed at N, 'parsers.pack_dirstate()'
      replaces timestamp N with "-1" before actual writing dirstate out.
      
      This issue can occur when 'hg transplant' satisfies conditions below:
      
        - multiple revisions to be transplanted change the same file
        - those revisions don't change mode and size of the file, and
        - the 2nd or later revision of them fails after changing the file
      
      The root cause of this issue is that files are changed without
      flushing in-memory dirstate changes via 'repo.commit()' (even though
      omitting 'dirstate.normallookup()' on files changed by 'patch.patch()'
      for efficiency also causes this issue).
      
      To detect changes of files correctly, this patch writes in-memory
      dirstate changes out explicitly after marking files as clean in
      'committablectx.markcommitted()', which is invoked via
      'repo.commit()'.
      
      After this change, timetable is changed as below:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
         *                                             ***    ***
             - 'hg transplant REV1 REV2 ...'
               - transplanting REV1
                 ....
         N
                 - change "f", but keep size                   N
                   (via 'patch.patch()')
                 - 'dirstate.normal("f")'          N    ***
                   (via 'repo.commit()')
             ----------------------------------- ---- ----- -----
                 - 'dirsttate.write()'            -1    -1
             ----------------------------------- ---- ----- -----
               - transplanting REV2
                 - change "f", but keep size                   N
                   (via 'patch.patch()')
                 - aborted while patching
        N+1
               - release wlock
                 - 'dirstate.write()'              -1   -1     N
      
             - 'hg status' shows "r1" as "clean"   -1   -1     N
        ---- ----------------------------------- ---- ----- -----
      
      To reproduce this issue in tests certainly, this patch emulates some
      timing critical actions as below:
      
        - change "f" at N
      
          'patch.patch()' with 'fakepatchtime.py' explicitly changes mtime
          of patched files to "2000-01-01 00:00" (= N).
      
        - 'dirstate.write()' via 'repo.commit()' at N
      
          'fakedirstatewritetime.py' forces 'pack_dirstate()' to use
          "2000-01-01 00:00" as "now", only if 'pack_dirstate()' is invoked
          via 'committablectx.markcommitted()'.
      
        - 'dirstate.write()' via releasing wlock at N+1 (or "not at N")
      
          'pack_dirstate()' via releasing wlock uses actual timestamp at
          runtime as "now", and it should be different from the "2000-01-01
          00:00" of "f".
      
      BTW, this patch doesn't test cases below, even though 'patch.patch()'
      is used similarly in these cases:
      
        1. failure of 'hg import' or 'hg qpush'
      
        2. success of 'hg import', 'hg qpush' or 'hg transplant'
      
      Case (1) above doesn't cause this kind of issue, because:
      
        - if patching is aborted by conflicts, changed files are committed
      
          changed files are marked as CLEAN, even though they are partially
          patched.
      
        - otherwise, dirstate are fully restored by 'dirstateguard'
      
          For example in timetable above, timestamp of "f" in .hg/dirstate
          is restored to -1 (or less than N), and subsequent 'hg status' can
          detect changes correctly.
      
      Case (2) always causes 'repo.status()' invocation via 'repo.commit()'
      just after changing files inside same wlock scope.
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              ***   ***
             - make file "f" clean                            N
      
             - execute 'hg foobar'
               ....
               - 'dirstate.normal("f")'           N    ***
                 (e.g. via dirty check
                  or previous 'repo.commit()')
      
               - change "f", but keep size                    N
               - 'repo.status()' (*1)
                 (via 'repo.commit()')
        ---- ----------------------------------- ---- ----- -----
      
      At a glance, 'repo.status()' at (*1) seems to cause similar issue (=
      "changed files are treated as clean"), but actually doesn't.
      
      'dirstate._lastnormaltime' should be N at (*1) above, because
      'dirstate.normal()' via dirty check is finished at N.
      
      Therefore, "f" changed at N (= 'dirstate._lastnormaltime') is forcibly
      treated as "unsure" at (*1), and changes are detected as expected (see
      'dirstate.status()' for detail).
      
      If 'hg import' is executed with '--no-commit', 'repo.status()' isn't
      invoked just after changing files inside same wlock scope.
      
      But preceding 'dirstate.normal()' is invoked inside another wlock
      scope via 'cmdutil.bailifchanged()', and in-memory changes should be
      flushed at the end of that scope.
      
      Therefore, timestamp N of clean "f" should be replaced by -1, if
      'dirstate.write()' is invoked at N. It means that condition of this
      issue isn't satisfied.
      4d1382fd
Loading