Skip to content
Snippets Groups Projects
  1. Jul 09, 2015
  2. Jul 02, 2015
  3. Jun 28, 2015
  4. 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
  5. 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
  6. 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
  7. Jul 04, 2015
  8. 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
    • Katsunori FUJIWARA's avatar
      tests: add extension to emulate invoking internalpatch at the specific time · a4a41525
      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.
      a4a41525
    • Katsunori FUJIWARA's avatar
      cmdutil: remove useless dirstate.normallookup() invocation in revert() · 72d395e3
      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).
      72d395e3
    • Katsunori FUJIWARA's avatar
      merge: remove useless dirstate.normallookup() invocation in applyupdates() · 19cc443a
      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).
      19cc443a
    • Katsunori FUJIWARA's avatar
      context: write dirstate out explicitly after marking files as clean · fe03f522
      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.
      fe03f522
    • Katsunori FUJIWARA's avatar
      tests: add extension to emulate invoking dirstate.write at the specific time · 815df73a
      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.
      815df73a
    • Eugene Baranov's avatar
    • Durham Goode's avatar
      convert: add config for recording the source name · c9093d4d
      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.
      c9093d4d
    • Durham Goode's avatar
      convert: support multiple specifed revs in git source · f2748cc4
      Durham Goode authored
      This allows specifying multiple revs/branches to convert from a git repo.
      f2748cc4
    • Durham Goode's avatar
      convert: add support for specifying multiple revs · baea47ca
      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).
      baea47ca
  9. Jul 05, 2015
    • Anton Shestakov's avatar
      monoblue: use padding instead of position for text in footer · 5a15236f
      Anton Shestakov authored
      Some installations alter monoblue style and remove margins from body element
      (these margins have that dark gray background) to adapt hgweb instance to an
      already existing site design. However, the margins hid a quirk in page footer:
      a block of text needlessly popped out of the footer, and when margins were
      gone, the whole page got a vertical scroll bar because of that.
      
      Live example: https://hg.prosody.im/prosody-modules/
      
      To remove the potential scroll bar, this block of text now uses left padding,
      which doesn't make it overflow the footer, but makes it achieve the otherwise
      same result visually.
      5a15236f
    • Anton Shestakov's avatar
      monoblue: don't try to show repo on hgwebdir index page · 0c3c0f12
      Anton Shestakov authored
      Index page shows a list of accessible repositories, it doesn't have a
      single-repo context.
      0c3c0f12
  10. Jul 03, 2015
  11. Sep 28, 2014
    • Pierre-Yves David's avatar
      bookmarks: change bookmark within a transaction · e78a80f8
      Pierre-Yves David authored
      For some time, bookmark can and should be moved in the transaction. This
      changeset migrates the 'hg bookmarks' commands to use a transaction.
      
      Tests regarding rollback and transaction hooks are impacted for
      obvious reasons. Some have to be slightly updated to keep testing the
      same things. Some can just be dropped because they do not make sense
      anymore.
      e78a80f8
  12. Jul 01, 2015
    • Pierre-Yves David's avatar
      bookmark: remove the "touch changelog" hack · ce45bfe8
      Pierre-Yves David authored
      Any changes to bookmarks used to touch the changelog to ensure hgweb was
      reloaded. This was fairly hacky and stops working when bookmarks are moved as
      part of the transaction. As hgweb is now explicitly tracking bookmark changes,
      we can remove this hack (and no tests break).
      ce45bfe8
  13. Jun 29, 2015
    • Durham Goode's avatar
      convert: add config option for disabling ancestor parent checks · d859123e
      Durham Goode authored
      When converting merge commits, convert checks if any of the parents are
      ancestors of any of the other parents. To do this, it builds an ancestor list
      for every commit in the repository. On large repos this can take a long time
      (30min+). Let's add an option for disabling this check to preserve performance.
      
      The downside of this is that it may create unnecessary parent connections when
      enabled (which is unfortunate, but not incorrect).
      
      To verify, I ran the convert tests with the flag enabled, and verified the graph
      changes were all just to add new parents that were ancestors of existing
      parents.
      d859123e
    • Durham Goode's avatar
      convert: add config to not convert tags · 86fe3c40
      Durham Goode authored
      In some cases we do not want to convert tags from the source repo to be tags in
      the target repo (for instance, in a large repository, hgtags cause scaling
      issues so we want to avoid them). This adds a config option to disable
      converting tags.
      86fe3c40
  14. Jul 02, 2015
  15. Jun 22, 2015
  16. Mar 14, 2015
    • Yuya Nishihara's avatar
      templatekw: apply manifest template only if ctx.manifestnode() exists · 8854ca3f
      Yuya Nishihara authored
      This will prevent crash by "hg log -r 'wdir()' -Tdefault". We could use the
      pseudo ff... hash introduced by 183965a00c76, but it isn't proven idea yet.
      For now, I want to make "hg log" just works in order to test 'wdir()' revset.
      
      Note that unlike its name, "{manifest}" is not a list of files in that
      revision, but a pair of (manifestrev, manifestnode).
      8854ca3f
  17. Jul 08, 2015
  18. Jul 04, 2015
Loading