Skip to content
Snippets Groups Projects
  1. Jul 14, 2015
    • Durham Goode's avatar
      convert: allow customizing git remote prefix · d9133e89d39d
      Durham Goode authored
      Previously all git remotes were created as "remote/foo". This patch adds a
      configuration option for deciding what the prefix should be. This is useful if
      you want the bookmarks to be "origin/foo" like they are in git, or if you're
      integrating with the remotenames extension and don't want the local remote/foo
      bookmarks to overlap with the remote foo bookmarks.
      d9133e89d39d
  2. Jul 12, 2015
  3. Jun 20, 2015
  4. Jun 21, 2015
  5. Jun 15, 2015
  6. Jul 12, 2015
    • Anton Shestakov's avatar
      hgweb: provide links to branches, tags and bookmarks by name (paper and coal) · cd842821db2c
      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.
      cd842821db2c
    • Anton Shestakov's avatar
      templates: introduce revescape filter for escaping symbolic revisions · 3a33412792f1
      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.
      3a33412792f1
    • Anton Shestakov's avatar
      hgweb: allow symbolic revisions with forward slashes in urls · 1c2a8db33b8f
      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.
      1c2a8db33b8f
  7. Jul 13, 2015
  8. Jul 08, 2015
    • Eugene Baranov's avatar
      convert: if getting a file from Perforce fails try to get it one more time · 220d9ae6a9a8
      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.
      220d9ae6a9a8
  9. Jul 13, 2015
    • Katsunori FUJIWARA's avatar
      shelve: keep old backups if timestamp can't decide exact order of them · 4f8c20fe66f0
      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.
      4f8c20fe66f0
  10. Jul 09, 2015
  11. Jul 02, 2015
  12. Jun 28, 2015
  13. Mar 16, 2015
    • Yuya Nishihara's avatar
      revset: use integer representation of wdir() in revset · 5e1b0739611c
      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.
      5e1b0739611c
  14. Aug 16, 2014
    • Yuya Nishihara's avatar
      localrepo: provide workingctx by integer revision · 22049b565d57
      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.
      22049b565d57
  15. Apr 12, 2015
    • Yuya Nishihara's avatar
      changeset_printer: change flush() to accept ctx instead of rev · 60c791592aa7
      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.
      60c791592aa7
  16. Jul 04, 2015
  17. Jul 08, 2015
    • Gregory Szorc's avatar
      hg: support for auto sharing stores when cloning · 0d37b9b21467
      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.
      0d37b9b21467
    • Matt Mackall's avatar
      merge with stable · 648323f41a89
      Matt Mackall authored
      648323f41a89
    • Katsunori FUJIWARA's avatar
      cmdutil: apply dirstate.normallookup on (maybe partially) committed files · ff11c1565c04
      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
      ff11c1565c04
    • Katsunori FUJIWARA's avatar
      cmdutil: put recordfunc invocation into wlock scope for consistency · c5dfa47ad7ee
      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".
      c5dfa47ad7ee
    • Katsunori FUJIWARA's avatar
      context: write dirstate out explicitly at the end of markcommitted · 4d1382fd96ff
      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.
      4d1382fd96ff
    • Katsunori FUJIWARA's avatar
      tests: add extension to emulate invoking internalpatch at the specific time · a4a41525180c
      Katsunori FUJIWARA authored
      This extension fakes "mtime" of patched files to emulate invoking
      'patch.internalpatch()' at the specific time.
      
      This is useful to reproduce timing critical issues fixed in subsequent
      patches.
      a4a41525180c
    • Katsunori FUJIWARA's avatar
      cmdutil: remove useless dirstate.normallookup() invocation in revert() · 72d395e399c1
      Katsunori FUJIWARA authored
      Explicit 'dirstate.normallookup()' invocation in 'revert()' is useless
      now, because previous patch fixed the relevant issue by writing
      in-memory dirstate changes out at the end of dirty check.
      
      'dirstate.normallookup()' invocation was introduced by 21b33f0460e0 to
      avoid occasional test failure (see issue4583 for detail). This is
      partial backout of it (added tests are still left).
      72d395e399c1
    • Katsunori FUJIWARA's avatar
      merge: remove useless dirstate.normallookup() invocation in applyupdates() · 19cc443aac34
      Katsunori FUJIWARA authored
      Explicit 'dirstate.normallookup()' invocation via 'dirtysubstate()' in
      'applyupdates()' is useless now, because previous patch fixed the
      relevant issue by writing in-memory dirstate changes out at the end of
      dirty check.
      
      'dirstate.normallookup()' invocation was introduced by 6becb9dbca25 to
      avoid occasional test failure. This is partial backout of it (added
      tests are still left).
      19cc443aac34
    • Katsunori FUJIWARA's avatar
      context: write dirstate out explicitly after marking files as clean · fe03f522dda9
      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                                              -1    ***
             - make file "f" clean                            N
      
             - execute 'hg foobar'
               - instantiate 'dirstate'           -1   -1
               - 'dirstate.normal("f")'           N    -1
                 (e.g. via dirty check)
               - change "f", but keep size                    N
        N+1
               - release wlock
                 - 'dirstate.write()'             N    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.
      
      Occasional test failure for unexpected file status is typical example
      of this corner case. Batch execution with small working directory is
      finished in no time, and rarely satisfies condition (2) above.
      
      This issue can occur in cases below;
      
        - 'hg revert --rev REV' for revisions other than the parent
        - failure of 'merge.update()' before 'merge.recordupdates()'
      
      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 changed files 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
      'workingctx._checklookup()', which is invoked via 'repo.status()'.
      
      After this change, timetable is changed as below:
      
        ---- ----------------------------------- ----------------
                                                 timestamp of "f"
                                                 ----------------
                                                 dirstate   file-
        time          action                     mem  file  system
        ---- ----------------------------------- ---- ----- -----
        N                                              -1    ***
             - make file "f" clean                            N
      
             - execute 'hg foobar'
               - instantiate 'dirstate'           -1   -1
               - 'dirstate.normal("f")'           N    -1
                 (e.g. via dirty check)
             ----------------------------------- ---- ----- -----
               - 'dirsttate.write()'              -1   -1
             ----------------------------------- ---- ----- -----
               - change "f", but keep size                    N
        N+1
               - release wlock
                 - 'dirstate.write()'             -1   -1
      
             - 'hg status'                        -1   -1      N
        ---- ----------------------------------- ---- ----- -----
      
      To reproduce this issue in tests certainly, this patch emulates some
      timing critical actions as below:
      
        - timestamp of "f" in '.hg/dirstate' is -1 at the beginning
      
          'hg debugrebuildstate' before command invocation ensures it.
      
        - make file "f" clean at N
        - change "f" at N
      
          'touch -t 200001010000' before and after command invocation
          changes mtime of "f" to "2000-01-01 00:00" (= N).
      
        - invoke 'dirstate.write()' via 'repo.status()' at N
      
          'fakedirstatewritetime.py' forces 'pack_dirstate()' to use
          "2000-01-01 00:00" as "now", only if 'pack_dirstate()' is invoked
          via 'workingctx._checklookup()'.
      
        - invoke '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 also changes 'test-largefiles-misc.t', because adding
      'dirstate.write()' makes recent dirstate changes visible to external
      process.
      fe03f522dda9
    • Katsunori FUJIWARA's avatar
      tests: add extension to emulate invoking dirstate.write at the specific time · 815df73abf12
      Katsunori FUJIWARA authored
      This extension fakes 'now' for 'parsers.pack_dirstate()' to emulate
      invoking 'dirstate.write()' at the specific time, only when
      'dirstate.write()' is invoked via functions below:
      
        - 'workingctx._checklookup()' (= 'repo.status()')
        - 'committablectx.markcommitted()'
      
      This is useful to reproduce timing critical issues fixed in subsequent
      patches.
      815df73abf12
    • Eugene Baranov's avatar
    • Durham Goode's avatar
      convert: add config for recording the source name · c9093d4d1ff6
      Durham Goode authored
      This creates the convert.hg.sourcename config option which will embed a user
      defined name into each commit created by the convert. This is useful when using
      the convert extension to merge several repositories together and we want to
      record where each commit came from.
      c9093d4d1ff6
    • Durham Goode's avatar
      convert: support multiple specifed revs in git source · f2748cc43b2a
      Durham Goode authored
      This allows specifying multiple revs/branches to convert from a git repo.
      f2748cc43b2a
    • Durham Goode's avatar
      convert: add support for specifying multiple revs · baea47cafe75
      Durham Goode authored
      Previously convert could only take one '--rev'. This change allows the user to
      specify multiple --rev entries. For instance, this could allow converting
      multiple branches (but not all branches) at once from git.
      
      In this first patch, we disable support for this for all sources.  Future
      patches will enable it for select sources (like git).
      baea47cafe75
Loading