Skip to content
Snippets Groups Projects
  1. Jul 31, 2012
  2. Aug 01, 2012
  3. Jul 31, 2012
    • Patrick Mézard's avatar
      transplant: handle non-empty patches doing nothing (issue2806) · a189d4470a34
      Patrick Mézard authored
      If patch.patch() reports patched files when applying a changeset and the
      following commit says nothing changed, transplant used to abort with a
      RuntimeError, assuming something went wrong with patching.
      
      The mismatch is patch.patch() reports patched files, not changed ones.
      It could be modified to report changed files but it means duplicating
      work from status, may be expensive in the case of binary files, and is
      probably not that useful at API level. For instance, if two patches are
      applied on the working directory, the outcome may be nothing changed
      while each call would have returned modified files. The caller would
      have to call status() itself again.
      
      This patch fixes the issue by trusting patching code: if the patch
      succeeded and commit reports nothing changed, then nothing changed,
      patch() did not "dropped changes on the floor".
      a189d4470a34
  4. Jul 29, 2012
    • Katsunori FUJIWARA's avatar
      histedit: make comment part of the file describing rules as translatable · f320d7ed912f
      Katsunori FUJIWARA authored
      "i18n.gettext()" invocation for "editcomment" itself should have
      little impact for whole initialization cost of histedit, because it is
      already invoked for initialization of the command table entry.
      
      '\n\n' has to be added to the text being edited separately from
      "editcomment", because leading 'line feed' characters are not exported
      to "hg.pot" file correctly.
      f320d7ed912f
  5. Jul 31, 2012
  6. Jul 30, 2012
  7. Jul 28, 2012
  8. Jul 29, 2012
  9. Jul 20, 2012
  10. Jul 21, 2012
    • Matt Harbison's avatar
      largefiles: fix a traceback introduced with recent peer changes · 32246faba53a
      Matt Harbison authored
      Changeset 1ac628cd7113 broke 'outgoing --large'
      
          ...
          File "hgext\largefiles\lfutil.py", line 56, in findoutgoing
            remote.local(), force=force)
          File "mercurial\discovery.py", line 31, in findcommonincoming
            if not remote.capable('getbundle'):
        AttributeError: 'lfilesrepo' object has no attribute 'capable'
      
      This restores the previous functionality, though I'm not sure if there's a
      better way to do this- that changeset introduces a hunk in debugdiscovery that
      does this:
      
                  if not util.safehasattr(remote, 'branches'):
                      # enable in-client legacy support
                      remote = localrepo.locallegacypeer(remote.local())
      
      Is there a legacy support issue here too?
      32246faba53a
  11. Jul 20, 2012
  12. Jul 25, 2012
    • Katsunori FUJIWARA's avatar
      doc: unify section level between help topics · 979b107eaea2
      Katsunori FUJIWARA authored
      Some help topics use "-" for the top level underlining section mark,
      but "-" is used also for the top level categorization in generated
      documents: "hg.1.html", for example.
      
      So, TOC in such documents contain "sections in each topics", too.
      
      This patch changes underlining section mark in some help topics to
      unify section level in generated documents.
      
      After this patching, levels of each section marks are:
      
        level0
        """"""
          level1
          ======
            level2
            ------
              level3
              ......
                level4
                ######
      
      And use of section markers in each documents are:
      
        - mercurial/help/*.txt can use level1 or more
          (now these use level1 and level2)
      
        - help for core commands can use level2 or more
          (now these use no section marker)
      
        - descriptions of extensions can use level2 or more
          (now hgext/acl uses level2)
      
        - help for commands defined in extension can use level4 or more
          (now "convert" of hgext/convert uses level4)
      
      "Level0" is used as top level categorization only in "doc/hg.1.txt"
      and the intermediate file generated by "doc/gendoc.py", so end users
      don't see it in "hg help" outoput and so on.
      979b107eaea2
  13. Jul 27, 2012
  14. Jul 26, 2012
  15. Jul 06, 2012
  16. Jul 26, 2012
  17. Jul 23, 2012
    • Matt Harbison's avatar
      largefiles: fix path handling for cp/mv (issue3516) · 6e84171a61c8
      Matt Harbison authored
      Previously, a copy or a move of a largefile only worked if the cwd was the root
      of the repository.  The first issue was that the destination path passed to
      os.mkdirs() chopped the absolute path to the standin after '.hglf/', which
      essentially created a path relative to the repository root.  Similarly, the
      second issue was that the source and dest paths for copyfile() were relative to
      the repo root.  This converts these three paths to absolute paths.
      
      Some notable issues, regardless of the directory in which the cp/mv is executed:
      
      1) The copy is not being recorded in lfdirstate, but it is in dirstate for the
      standins.  I'm not sure if this is by design (i.e. minimal info in lfdirstate).
      
      2) status -C doesn't behave as expected.  Using the testcase as an example:
      
        # after mv + ci
        $ hg status -C -v --rev '.^'     # expected to see 'A' and ' ' lines too
        R dira\dirb\largefile
      
        $ hg status -C -v --rev '.^' foo/largefile
        # no output                      # expected to see 'A' and ' ' lines only
      
        $ hg status -C -v --rev '.^' foo/
        # no output                      # expected to see 'A', ' ' and 'R' lines
      
        $ hg status -C -v --rev '.^' ./  # expected to see 'A' and ' ' lines too
        R dirb\largefile
      
        $ hg status -C -v --rev '.^' ../.hglf/dira/foo/largefile
        A ..\.hglf\dira\foo\largefile
          ..\.hglf\dira\dirb\largefile  # no 'R' expected when new file is specified
      
        $ hg status -C -v --rev '.^' ../.hglf   # OK
        A ..\.hglf\dira\foo\largefile
          ..\.hglf\dira\dirb\largefile
        R ..\.hglf\dira\dirb\largefile
      6e84171a61c8
  18. Jul 25, 2012
    • Patrick Mézard's avatar
      histedit: fix new nodes computation with --continue (issue3534) · 336121088ef1
      Patrick Mézard authored
      When running the following actions:
      
        pick 617f94f13c0f 1 +4
        drop 888f9082bf99 2 +5
        fold 251d831eeec5 3 +6
      
      if the fold fails, is fixed by the user with a new changeset, --continue
      will ignore the new revision when generating the fold changelog. This
      was caused by --continue detecting new changesets as descendants of the
      parent not descendants of changesets in the initial list. In this case,
      dropped changesets must be ignored.
      
      Even with the computation fixed, the 'newchildren' list was always
      emptied by the filtering loop and passed empty to finishfold().
      
      Note that changesets dropped and recreated identically will still be
      missed. This probably cannot be solved but is unlikely to happen.
      
      Other things, like 'newchildren' having multiple heads, should be
      checked as well.
      336121088ef1
    • Patrick Mézard's avatar
      histedit: end folding message with an LF · c2f13180001f
      Patrick Mézard authored
      This is convenient when running tests dumping the editor content, it
      avoids the following output line to be mixed with histedit message.
      c2f13180001f
  19. Jul 21, 2012
  20. Jul 20, 2012
    • Matt Harbison's avatar
      largefiles: ensure addlargefiles() doesn't add a standin as a largefile · 25248e2ebaee
      Matt Harbison authored
      An easy way to force this (and cause a traceback) prior to the fix for 3507 was
      
        $ touch large
        $ hg add --large large
        $ hg ci -m "add"
        $ hg remove large
        $ touch large
        $ hg addremove --config largefiles.patterns=**large
      
      This patch also detected (and corrected) a previous test where a standin got
      added as a largefile (without a traceback).
      25248e2ebaee
  21. Jul 19, 2012
    • Matt Harbison's avatar
      largefiles: fix a traceback when addremove follows a remove (issue3507) · 2446b63c89ec
      Matt Harbison authored
      The problem only occurred if a file was removed with 'hg rm' (as opposed to the
      OS utilities), and then addremove was run before a commit.  Both normal and
      large files were affected.
      
      Ensuring that the file exists prior to an lstat() for size seems like the Right
      Thing.  But oddly enough, the missing file that was causing lstat() to blow up
      was a standin when a largefile was removed, which seems fishy, because a standin
      should never be added as a largefile.  I was then able to get a standin added as
      a largefile (whose name is 'large') with
      
         hg addremove --config largefiles.patterns=**large
      
      which also causes a backtrace.  That will be fixed next.
      2446b63c89ec
    • Matt Harbison's avatar
      largefiles: defer lfdirstate.drop() until after commit (issue3364) · fc4c155658b7
      Matt Harbison authored
      The example in comment #9 of the bug writeup must be run exactly- it was the
      commit after the rm and prior to the addremove that screwed things up, because
      that commit noticed that the largefile was missing, called drop(), and then the
      original commit function did nothing (due to the file in the '!' state).  The
      addremove command properly put it into the 'R' state, but it remained stuck in
      that state (because commit insisted 'nothing changed').  Without the commit
      prior to addremove, the problem didn't occur.
      
      Maybe this is an indication that lfdirstate needs to take a few more hints from
      the regular dirstate, regardless of what _it_ thinks the state is- similar
      inconsistency is probably still possible with this patch if the original commit
      succeeds but the lfdirstate write fails.
      fc4c155658b7
    • Matt Harbison's avatar
      largefiles: fix addremove with -R option · a6d9b2d33040
      Matt Harbison authored
      If a file was missing, the missing list contained a path relative to the repo.
      When building the matcher from that list, the file name ended up concatenated to
      cwd, causing the command to abort with '<file> not under root'.  This rebuilds
      the missing list with paths relative to cwd.
      a6d9b2d33040
  22. Jul 13, 2012
    • Peter Arrenbrecht's avatar
      peer: introduce real peer classes · 1ac628cd7113
      Peter Arrenbrecht authored
      This change separates peer implementations from the repository implementation.
      localpeer currently is a simple pass-through to localrepository, except for
      legacy calls, which have already been removed from localpeer. This ensures that
      the local client code only uses the most modern peer API when talking to local
      repos.
      
      Peers have a .local() method which returns either None or the underlying
      localrepository (or descendant thereof). Repos have a .peer() method to return
      a freshly constructed localpeer. The latter is used by hg.peer(), and also to
      allow folks to pass either a peer or a repo to some generic helper methods.
      We might want to get rid of .peer() eventually.
      
      The only user of locallegacypeer is debugdiscovery, which uses it to pose as a
      pre-setdiscovery client. But we decided to leave the old API defined in
      locallegacypeer for clarity and maybe for other uses in the future.
      
      It might be nice to actually define the peer API directly in peer.py as stub
      methods. One problem there is, however, that localpeer implements
      lock/addchangegroup, whereas the true remote peers implement unbundle.
      It might be desireable to get rid of this distinction eventually.
      1ac628cd7113
    • Sune Foldager's avatar
      peer: introduce peer methods to prepare for peer classes · 5884812686f7
      Sune Foldager authored
      This introduces a peer method into all repository classes, which currently
      simply returns self. It also changes hg.repository so it now raises an
      exception if the supplied paths does not resolve to a localrepo or descendant.
      
      Finally, all call sites are changed to use the peer and local methods as
      appropriate, where peer is used whenever the code is dealing with a remote
      repository (even if it's on local disk).
      5884812686f7
  23. Jul 16, 2012
  24. Jul 11, 2012
  25. Jul 14, 2012
  26. Jul 11, 2012
  27. Jun 24, 2012
  28. Jul 14, 2012
  29. Jul 15, 2012
  30. Jul 06, 2012
    • Wagner Bruna's avatar
      convert: make filemap renames consistently override revision renames · 32b2e6d641e4
      Wagner Bruna authored
      When the source repository had a revision renaming "$new -> $old",
      but the filemap a "$old -> $new" rename, the converted revision could
      use either $new (deleting the file) or $old (keeping the file) when
      getting the file data, depending on the lexicographical order of
      those names. So the resulting revision would leave some files
      untouched (as expected), but delete others arbitrarely.
      32b2e6d641e4
  31. Jul 11, 2012
Loading