Skip to content
Snippets Groups Projects
  1. Sep 01, 2014
    • David Soria Parra's avatar
      rebase: add a deprecated -i/--interactive flag · d5b04ee8ecf7
      David Soria Parra authored
      A common mistake can be to type 'hg rebase -i' to discover interactive history
      editing. We add a -i/--interactive flag as discussed in the sprint and deprecate
      it right away, but hint people using it to use histedit instead.
      d5b04ee8ecf7
  2. Sep 07, 2014
  3. Sep 03, 2014
  4. Aug 31, 2014
  5. Aug 26, 2014
    • Mads Kiilerich's avatar
      convert: introduce --full for converting all files · 35ab037de989
      Mads Kiilerich authored
      Convert will normally only process files that were changed in a source
      revision, apply the filemap, and record it has a change in the target
      repository. (If it ends up not really changing anything, nothing changes.)
      
      That means that _if_ the filemap is changed before continuing an incremental
      convert, the change will only kick in when the files it affects are modified in
      a source revision and thus processed.
      
      With --full, convert will make a full conversion every time and process
      all files in the source repo and remove target repo files that shouldn't be
      there. Filemap changes will thus kick in on the first converted revision, no
      matter what is changed.
      
      This flag should in most cases not make any difference but will make convert
      significantly slower.
      
      Other names has been considered for this feature, such as "resync", "sync",
      "checkunmodified", "all" or "allfiles", but I found that they were less obvious
      and required more explanation than "full" and were harder to describe
      consistently.
      35ab037de989
    • Mads Kiilerich's avatar
      convert: refactor hg getchanges and caching · 98aafdf4cbf6
      Mads Kiilerich authored
      98aafdf4cbf6
    • Mads Kiilerich's avatar
      4ba35d4298a0
    • Mads Kiilerich's avatar
      convert: remove incorrect and unused handling of removed svn directories · a74d05878a8d
      Mads Kiilerich authored
      Since it was introduced in f0c58fd4b798, tidy_dirs has been comparing
      the result of os.listdir with a string - which never can be true.
      Convert apparently works anyway and there is no test coverage of it.
      
      It also seems like it could make a bigger difference on older svn versions but
      is less relevant with more recent versions.
      
      Instead of trying to fix the code, we take the low risk option and remove it.
      a74d05878a8d
    • Mads Kiilerich's avatar
      convert: use None value for missing files instead of overloading IOError · 650b5b6e75ed
      Mads Kiilerich authored
      The internal API used IOError to indicate that a file should be marked as
      removed.
      
      There is some correlation between IOError (especially with ENOENT) and files
      that should be removed, but using IOErrors to represent file removal internally
      required some hacks.
      
      Instead, use the value None to indicate that the file not is present.
      
      Before, spurious IO errors could cause commits that silently removed files.
      They will now be reported like all other IO errors so the root cause can be
      fixed.
      650b5b6e75ed
  6. Aug 25, 2014
    • Mads Kiilerich's avatar
      convert: p4: ignore purged files with p4d 2012.2 and later · 754f208ce21d
      Mads Kiilerich authored
      Perforce has the concept of "+Sn" files where only the last revisions of the
      file is stored. In p4d 2012.1 old purged revisions were not included in the
      "manifest". With 2012.2 they started being included and convert's getfile
      failed to recognize the "purged" flag and saw it as an empty file. That made
      test-convert-p4-filetypes.t fail.
      
      There is no point in storing an empty file as placeholder for a purged file so
      we restore the old behaviour by checking the flag and letting getfile consider
      purged files deleted.
      
      (It is questionable whether it makes sense to convert not-yet-purged +S files
      to mercurial ... but that is another question.)
      754f208ce21d
  7. Aug 24, 2014
    • Katsunori FUJIWARA's avatar
      largefiles: remove redundant "updatelfiles" invocation in "lfilesrepo.commit" · dcb95aadf850
      Katsunori FUJIWARA authored
      After previous patches, largefiles in the working directory are
      ensured to be updated before "repo.commit" invocation for automated
      committing below:
      
        - by "overrides.mergeupdate" via "merge.update" for rebase
        - by "overrides.scmutilmarktouched" via "patch.patch" for transplant
      
      This patch removes redundant "lfcommands.updatelfiles" invocation in
      "Case 0" code path of "lfilesrepo.commit" for automated committing,
      and revises detailed comment.
      dcb95aadf850
    • Katsunori FUJIWARA's avatar
      largefiles: update largefiles even if transplant is aborted by conflict · e26df4e774f6
      Katsunori FUJIWARA authored
      Before this patch, largefiles in the working directory aren't updated
      correctly, if transplant is aborted by conflict. This prevents users
      from viewing appropriate largefiles while resolving conflicts.
      
      While transplant, largefiles in the working directory are updated only
      at successful committing in the special code path of
      "lfilesrepo.commit()".
      
      To update largefiles even if transplant is aborted by conflict, this
      patch wraps "scmutil.marktouched", which is invoked from "patch.patch"
      with "files" list of added/modified/deleted files.
      
      This patch invokes "updatelfiles" with:
      
        - "printmessage=False", to suppress "getting changed largefiles ..."
          messages while automated committing by transplant
      
        - "normallookup=True", because "patch.patch" doesn't update dirstate
          for modified files
      
          in such case, "normallookup=False" may cause marking modified
          largefiles as "clean" unexpectedly
      e26df4e774f6
    • Katsunori FUJIWARA's avatar
      largefiles: update largefiles even if rebase is aborted by conflict · 4e2559841d6c
      Katsunori FUJIWARA authored
      Before this patch, largefiles in the working directory aren't updated
      correctly, if rebase is aborted by conflict. This prevents users from
      viewing appropriate largefiles while resolving conflicts.
      
      While rebase, largefiles in the working directory are updated only at
      successful committing in the special code path of
      "lfilesrepo.commit()".
      
      To update largefiles even if rebase is aborted by conflict, this patch
      centralizes the logic of updating largefiles in the working directory
      into the "mergeupdate" wrapping "merge.update".
      
      
      This is a temporary way to fix with less changes. For fundamental
      resolution of this kind of problems in the future, largefiles in the
      working directory should be updated with other (normal) files
      simultaneously while "merge.update" execution: maybe by hooking
      "applyupdates".
      
      "Action list based updating" introduced by hooking "applyupdates" will
      also improve performance of updating, because it automatically
      decreases target files to be checked.
      
      
      Just after this patch, there are some improper things in "Case 0" code
      path of "lfilesrepo.commit()":
      
        - "updatelfiles" invocation is redundant for rebase
        - detailed comment doesn't meet to rebase behavior
      
      These will be resolved after the subsequent patch for transplant,
      because this code path is shared with transplant.
      
      
      Even though replacing "merge.update" in rebase extension by "hg.merge"
      can also avoid this problem, this patch chooses centralizing the logic
      into "mergeupdate", because:
      
        - "merge.update" invocation in rebase extension can't be directly
          replaced by "hg.merge", because:
      
          - rebase requires some extra arguments, which "hg.merge" doesn't
            take (e.g. "ancestor")
      
          - rebase doesn't require statistics information forcibly displayed
            in "hg.merge"
      
        - introducing "mergeupdate" can resolve also problem of some other
          code paths directly using "merge.update"
      
          largefiles in the working directory aren't updated regardless of
          the result of commands below, before this patch:
      
          - backout (for revisions other than the parent revision of the
            working directory without "--merge")
      
          - graft
      
          - histedit (for revisions other than the parent of the working
            directory
      
      
      When "partial" is specified, "merge.update" doesn't update dirstate
      entries for standins, even though standins themselves are updated.
      
      In this case, "normallookup" should be used to mark largefiles as
      "possibly dirty" forcibly, because applying "normal" on lfdirstate
      treats them as "clean" unexpectedly.
      
      This is reason why "normallookup=partial" is specified for
      "lfcommands.updatelfiles".
      
      
      This patch doesn't test "hg rebase --continue", because it doesn't
      work correctly if largefiles in the working directory are modified
      manually while resolving conflicts. This will be fixed in the next
      step of refactoring for largefiles.
      
      All changes of tests/*.t files other than test-largefiles-update.t in
      this patch come from invoking "updatelfiles" not after but before
      statistics output of "hg.update", "hg.clean" and "hg.merge".
      4e2559841d6c
    • Katsunori FUJIWARA's avatar
      largefiles: move "updatestandin" invocation to "hg.updaterepo" wrapper · f3ac9677fa2b
      Katsunori FUJIWARA authored
      Code paths below expect "hg.updaterepo" (or "hg.update" using it) to
      execute linear merging:
      
        - "update" in commands
        - "postincoming" in commands, used for:
          - "hg pull --update"
          - "hg unbundle --update"
        - "hgsubrepo.get" in subrepo
      
      For linear merging with largefiles, standins should be updated
      according to (possibly dirty) largefiles before "merge.update"
      invocation to detect conflicts correctly.
      
      Before this patch, only the "update" command can execute linear merging
      correctly, because largefiles extension takes care of only it.
      
      This patch moves "updatestandin" invocation from "overrideupdate" ("hg
      update" wrapper) to "_hgupdaterepo" ("hg.updaterepo" wrapper) to
      execute linear merging in "hg.updaterepo" correctly.
      
      This is also a preparation to centralize the logic of updating
      largefiles in the working directory into the function wrapping
      "merge.update" in the subsequent patch.
      f3ac9677fa2b
    • Katsunori FUJIWARA's avatar
      largefiles: unlink standins not known to the restored dirstate at rollback · 3f3b9483e7ef
      Katsunori FUJIWARA authored
      Before this patch, standinds not known to the restored dirstate at
      rollback still exist after rollback of the parent of the working
      directory, and they become orphans unexpectedly.
      
      This patch unlinks standins not known to the restored dirstate.
      
      This patch saves names of standins matched against not
      "repo.dirstate[f] == 'a'" but "repo.dirstate[f] != 'r'" before
      rollback, because branch merging marks files newly added to
      dirstate as not "a" but "n".
      
      Such standins will also become orphan after rollback, because they are
      not known to the restored dirstate.
      3f3b9483e7ef
    • Katsunori FUJIWARA's avatar
      largefiles: restore standins according to restored dirstate · 85bded43cc80
      Katsunori FUJIWARA authored
      Before this patch, standins are restored from the NEW parent of the
      working directory at "hg rollback", and this causes:
      
        - standins removed in the rollback-ed revision are restored, and
          become orphan, because they are already marked as "R" in the
          restored dirstate and expected to be unlinked
      
        - standins added in the rollback-ed revision are left as they were
          before rollback, because they are not included in the new parent
          (this may not be so serious)
      
      This patch replaces the "merge.update" invocation with a specific
      implementation to restore standins according to restored dirstate.
      
      This is also the preparation to centralize the logic of updating
      largefiles into the function wrapping "merge.update" in the subsequent
      patch.
      
      After that patch, "merge.update" will also update largefiles in the
      working directory and be redundant for restoring standins only.
      85bded43cc80
    • Katsunori FUJIWARA's avatar
      largefiles: restore standins from non branch-tip parent at rollback correctly · 72b378658cff
      Katsunori FUJIWARA authored
      Before this patch, "hg rollback" can't restore standins correclty, if:
      
        - old parent of the working directory is rollback-ed, and
        - new parent of the working directory is not branch-tip
      
      "overriderollback" uses "merge.update" as a kind of "revert" utility
      to restore only standins with "node=None", and this makes
      "merge.update" choose "branch-tip" revision as the updating target
      unexpectedly.
      
      Then, "merge.update" restores standins from the branch-tip revision
      regardless of the parent of the working directory after rollback and
      this may cause unexpected behavior.
      
      This patch invokes "merge.update" with "node='.'" to restore standins
      from the parent revision of the working directory.
      
      In fact, this "merge.update" invocation will be replaced in the
      subsequent patch to fix another problem, but this change is usefull to
      inform reason why such complicated case should be tested.
      72b378658cff
    • Katsunori FUJIWARA's avatar
      largefiles: omit restoring standins if working parent is not rollbacked · cb556ea76dcd
      Katsunori FUJIWARA authored
      For efficiency, this patch omits restoring standins and updating
      lfdirstate, if the parent of the working directory is not rollbacked.
      
      This patch adds the test not to confirm whether restoring is skipped
      or not, but to detect unexpected regression in the future: it is
      difficult to distinguish between skipping and perfectly restoring.
      cb556ea76dcd
  8. Aug 22, 2014
  9. Aug 21, 2014
    • durin42's avatar
      cvsps: add two more tiebreakers in cscmp · 90cf454edd70
      durin42 authored
      test-convert-cvs.t has been a little flaky for a while now. Add an
      extra tiebreaker in cscmp so that all the cases in the test will sort
      reliably.
      
      Without this patch, test-convert-cvs.t failed after 346 runs. With
      this patch, I stopped trying to get it to fail after 615 runs. While
      not conclusive, that makes me pretty optimistic that this is a working
      fix.
      90cf454edd70
  10. Aug 20, 2014
    • Siddharth Agarwal's avatar
      purge: avoid full walks when directories aren't purged · fe22d86a8992
      Siddharth Agarwal authored
      If match.traversedir is not None, we're forced to do full walks. However when
      we aren't purging directories we don't need to set match.traversedir to
      anything.
      
      This speeds up non-full walks such as the one hgwatchman makes possible. For
      mozilla-central with hgwatchman enabled, 'hg purge --files' goes from 0.88
      seconds to 0.22.
      fe22d86a8992
  11. Aug 16, 2014
    • Katsunori FUJIWARA's avatar
      transplant: change "editform" to distinguish merge commits from others · de783f2403c4
      Katsunori FUJIWARA authored
      "editform" argument for "getcommiteditor" is decided according to the
      format below:
      
        EXTENSION[.COMMAND][.ROUTE]
      
        - EXTENSION: name of extension
        - COMMAND: name of command, if there are two or more commands in EXTENSION
        - ROUTE: name of route, if there are two or more routes in COMMAND
      
      This patch newly adds "normal" and "merge" as ROUTE, to distinguish
      merge commits from other.
      
      This patch adds 4 test patterns to test combination of "merge"(x2) and
      "--continue"(x2).
      de783f2403c4
    • Katsunori FUJIWARA's avatar
      rebase: change "editform" to distinguish merge commits from others · d0d3e5c6eb3c
      Katsunori FUJIWARA authored
      "editform" argument for "getcommiteditor" is decided according to the
      format below:
      
        EXTENSION[.COMMAND][.ROUTE]
      
        - EXTENSION: name of extension
        - COMMAND: name of command, if there are two or more commands in EXTENSION
        - ROUTE: name of route, if there are two or more routes in COMMAND
      
      This patch newly adds "merge" as ROUTE, to distinguish merge commits
      from other.
      
      This patch passes bool as "ctxorbool" to "mergeeditform", because
      working context has always 2 parents at this point. Dropping the
      second parent of non-merging commits is executed in "concludenode".
      
      Unlike other patches in this series (e.g. for "hg commit"), this patch
      doesn't add "normal.normal"/"normal.merge" style ROUTEs, because there
      is no "merge" case in "collapse" ROUTE.
      d0d3e5c6eb3c
  12. Aug 15, 2014
    • Katsunori FUJIWARA's avatar
      rebase: use "rebase.collapse" as "editform" for "--collapse" always · 6122ad50e38f
      Katsunori FUJIWARA authored
      Before this patch, if both "--message" and "--collapse" are specified
      for "hg rebase", "rebaes.normal" is used as "editform" unexpectedly.
      
      Unlike patches before and after in this series for improvement, this
      is bug fix patch.
      6122ad50e38f
    • Mads Kiilerich's avatar
      cleanup: remove some unused / duplicate imports · 684bad8c4265
      Mads Kiilerich authored
      684bad8c4265
    • Mads Kiilerich's avatar
      cleanup: fix some list comprehension redefinitions of existing vars · 269688a398c4
      Mads Kiilerich authored
      In all the remaining cases the comprehension variable is used for the same
      thing as a previous loop variable.
      
      This will mute some pyflakes "list comprehension redefines" warnings.
      269688a398c4
    • Mads Kiilerich's avatar
      cleanup: avoid _ for local unused tmp variables - that is reserved for i18n · b3e51675f98e
      Mads Kiilerich authored
      _ is usually used for i18n markup but we also used it for I-don't-care
      variables.
      
      Instead, name don't-care variables in a slightly descriptive way but use the _
      prefix to designate unused variable.
      
      This will mute some pyflakes "import '_' ... shadowed by loop variable"
      warnings.
      b3e51675f98e
    • Katsunori FUJIWARA's avatar
      largefiles: update lfdirstate for unchanged largefiles during linear merging · f72d73937853
      Katsunori FUJIWARA authored
      Before this patch, linear merging of modified largefiles causes
      an unexpected result, if (1) largefile collides with same-name normal one
      in the target revision and (2) "local" largefile is chosen, even
      though branch merging between such revisions works correctly.
      
      Expected result of such linear merging is marking the largefile as
      (re-)"added", but the actual result is marking it as "modified".
      
      The standin of modified "local largefile" is not changed by linear
      merging, and updating/merging update lfdirstate entries only for
      largefiles of which standins are changed.
      
      This patch adds the code path to update lfdirstate only for largefiles
      of which standins are not changed.
      
      In this case, "synclfdirstate" should be invoked with True as
      "normallookup" argument always to force using "normallookup" on
      dirstate for "n" files, because "normal" may mark target files as
      "clean" unexpectedly.
      
      To reduce cost of "lfile not in filelist", this patch converts
      "filelist" to a "set" object: "filelist" is used only in (1) the newly
      added code path and (2) the next line of "filelist = set(filelist)".
      
      This is a temporary way to fix with less changes. For fundamental
      resolution of this kind of problems in the future, "lfdirstate" should
      be updated with "dirstate" simultaneously during "merge.update"
      execution: maybe by hooking "recordupdates" (+ total refactoring
      around lfdirstate handling)
      f72d73937853
    • Katsunori FUJIWARA's avatar
      largefiles: keep largefiles from colliding with normal one during linear merge · 23fe278bde43
      Katsunori FUJIWARA authored
      Before this patch, linear merging of modified or newly added largefile
      causes unexpected result, if (1) largefile collides with same name
      normal one in the target revision and (2) "local" largefile is chosen,
      even though branch merging between such revisions doesn't.
      
      Expected result of such linear merging is:
      
        (1) (not yet recorded) largefile is kept in the working directory
        (2) largefile is marked as (re-)"added"
        (3) colliding normal file is marked as "removed"
      
      But actual result is:
      
        (1) largefile in the working directory is unlinked
        (2) largefile is marked as "normal" (so treated as "missing")
        (3) the dirstate entry for colliding normal file is just dropped
      
      (1) is very serious, because there is no way to restore temporarily
      modified largefiles.
      
      (3) prevents the next commit from adding the manifest with correct
      "removal of (normal) file" information for newly created changeset.
      
      The root cause of this problem is putting "lfile" into "actions['r']"
      in linear-merging case. At liner merging, "actions['r']" causes:
      
        - unlinking "target file" in the working directory, but "lfile" as
          "target file" is also largefile itself in this case
      
        - dropping the dirstate entry for target file
      
      "actions['f']" (= "forget") does only the latter, and this is reason
      why this patch doesn't choose putting "lfile" into it instead of
      "actions['r']".
      
      This patch newly introduces action "lfmr" (LargeFiles: Mark as
      Removed) to mark colliding normal file as "removed" without unlinking
      it.
      
      This patch uses "hg debugdirstate" instead of "hg status" in test,
      because:
      
        - choosing "local largefile" hides "removed" status of "remote
          normal file" in "hg status" output, and
      
        - "hg status" for "large2" in this case has another problem fixed in
          the subsequent patch
      23fe278bde43
    • Katsunori FUJIWARA's avatar
      largefiles: put whole "hgmerge" process into the same "wlock" scope · 216942807308
      Katsunori FUJIWARA authored
      Before this patch, there are two distinct "wlock" scopes below in
      "hgmerge":
      
        1. "merge.update" via original "hg.merge" function
        2. "updatelfiles" specific "wlock" scope (to synchronize largefile
           dirstate)
      
      But these should be executed in the same "wlock" scope for
      consistency, because users of "hg.merge" don't get "wlock" explicitly
      before invocation of it.
      
        - merge in commands
      
      This patch puts almost all of the original "hgmerge" implementation into
      "_hgmerge" to reduce changes.
      216942807308
    • Katsunori FUJIWARA's avatar
      largefiles: put whole "hgupdaterepo" process into the same "wlock" scope · efc591e8b35c
      Katsunori FUJIWARA authored
      Before this patch, there are two distinct "wlock" scopes below in
      "hgupdaterepo":
      
        1. "merge.update" via original "hg.updaterepo" function
        2. "updatelfiles" specific "wlock" scope (to synchronize largefile
           dirstate)
      
      In addition to them, "dirstate.walk" is executed between these "wlock"
      scopes.
      
      But these should be executed in the same "wlock" scope for
      consistency, because many (indirect) users of "hg.updaterepo" don't
      get "wlock" explicitly before invocation of it.
      
      "hg.clean" is invoked without "wlock" from:
      
        - mqrepo.restore in mq
        - bisect in commands
        - update in commands
      
      "hg.update" is invoked without "wlock" from:
      
        - clone in mq
        - pullrebase in rebase
        - postincoming in commands (used in "hg pull -u", "hg unbundle")
        - update in commands
      
      This patch puts almost all original "hgupdaterepo" implementation into
      "_hgupdaterepo" to reduce changes.
      efc591e8b35c
    • Matt Mackall's avatar
      unshelve: silence internal revert · fb8065de47b0
      Matt Mackall authored
      This prepares for upcoming revert changes.
      fb8065de47b0
  13. Aug 14, 2014
  14. Aug 13, 2014
  15. Aug 14, 2014
  16. Aug 06, 2014
  17. Aug 13, 2014
    • Martin von Zweigbergk's avatar
      histedit: preserve initial author on fold (issue4296) · 9ac98c2aa95c
      Martin von Zweigbergk authored
      When the authorship of the changeset folded in does not match that of
      the base changeset, we currently use the configured ui.username
      instead. This is especially surprising when the user is not the author
      of either of the changesets. In such cases, the resulting authorship
      (the user's) is clearly incorrect. Even when the user is folding in a
      patch they authored themselves, it's not clear whether they should
      take over the authorship. Let's instead keep it simple and always
      preserve the base changeset's authorship. This is also how
      "git rebase -i" handles folding/squashing.
      9ac98c2aa95c
Loading