Skip to content
Snippets Groups Projects
  1. Jun 06, 2012
  2. Jul 26, 2012
  3. Jul 27, 2012
  4. Jul 26, 2012
  5. Jul 24, 2012
  6. Jul 26, 2012
  7. Jul 06, 2012
  8. Jul 25, 2012
    • Pierre-Yves David's avatar
      clone: copy obsolete markers during local clone · 7d4747c711a9
      Pierre-Yves David authored
      This change adds `obsstore` to the list of files copied by local clone,
      until now changesets were copied without their obsolete markers.
      
      Note: extinct changesets were and are still included by such clones to
      enable hardlinking. There is no obvious reason to prevent their exchange
      here.
      
      Rebased by Patrick Mezard <patrick@mezard.eu>
      7d4747c711a9
    • Patrick Mézard's avatar
      discovery: add extinct changesets to outgoing.excluded · 6ffb35b2284c
      Patrick Mézard authored
      Before this change, push would incorrectly fast-path the bundle
      generation when extinct changesets are involved, because they are not
      added to outgoing.excluded. The reason to do so are related to
      outgoing.excluded being assumed to contain only secret changesets by
      scmutil.nochangesfound(), when displaying warnings like:
      
       changes found (ignored 9 secret changesets)
      
      Still, outgoing.excluded seems like a good API to report the extinct
      changesets instead of dedicated code and nothing in the docstring
      indicates it to be bound to secret changesets. This patch adds extinct
      changesets to outgoing.excluded and fixes scmutil.nochangesfound() to
      filter the excluded node list.
      
      Original version and test by Pierre-Yves.David@ens-lyon.org
      6ffb35b2284c
  9. Jul 26, 2012
  10. Jul 25, 2012
  11. 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
  12. Jul 25, 2012
    • Katsunori FUJIWARA's avatar
    • Matt Mackall's avatar
      hgweb: improve colors for comparison page · 106cdea0183d
      Matt Mackall authored
      delete: red -> red
      insert: green -> yellow
      change: yellow -> gray
      106cdea0183d
    • 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
  13. Jul 24, 2012
  14. Jul 23, 2012
    • Jens Bäckman's avatar
      i18n-sv: synchronized with d1b49b02bc16 · 848a1c1e51cd
      Jens Bäckman authored
      848a1c1e51cd
    • Bryan O'Sullivan's avatar
      merge with crew-stable · 57a47190e96c
      Bryan O'Sullivan authored
      57a47190e96c
    • Bryan O'Sullivan's avatar
      e73128535105
    • Martin Geisler's avatar
      encoding: add fast-path for ASCII uppercase. · 9fb8312dbdbd
      Martin Geisler authored
      This copies the performance hack from encoding.lower (c481761033bd).
      
      The case-folding logic that kicks in on case-insensitive filesystems
      hits encoding.upper hard: with a repository with 75k files, the
      timings went from
      
        hg perfstatus
        ! wall 3.156000 comb 3.156250 user 1.625000 sys 1.531250 (best of 3)
      
      to
      
        hg perfstatus
        ! wall 2.390000 comb 2.390625 user 1.078125 sys 1.312500 (best of 5)
      
      This is a 24% decrease. For comparison, Mercurial 2.0 gives:
      
        hg perfstatus
        ! wall 2.172000 comb 2.171875 user 0.984375 sys 1.187500 (best of 5)
      
      so we're only 10% slower than before we added the extra case-folding
      logic.
      
      The same decrease is seen when executing 'hg status' as normal, where
      we go from:
      
        hg status --time
        time: real 4.322 secs (user 2.219+0.000 sys 2.094+0.000)
      
      to
      
        hg status --time
        time: real 3.307 secs (user 1.750+0.000 sys 1.547+0.000)
      9fb8312dbdbd
    • Martin Geisler's avatar
      encoding: use s.decode to trigger UnicodeDecodeError · 3745ae495ce5
      Martin Geisler authored
      When calling encode on a str, the string is first decoded using the
      default encoding and then encoded. So
      
        s.encode('ascii') == s.decode().encode('ascii')
      
      We don't care about the encode step here -- we're just after the
      UnicodeDecodeError raised by decode if it finds a non-ASCII character.
      
      This way is also marginally faster since it saves the construction of
      the extra str object.
      3745ae495ce5
  15. Jul 22, 2012
    • Adrian Buehlmann's avatar
      test-largefiles: fix test failing on vfat file systems · 0cfece81e051
      Adrian Buehlmann authored
      The usercache hardlinks files for filesystems that support hardlinks. So when
      this test is run on a filesystem that supports hardlinking, we have a link
      in r7 and in the usercache, pointing to the same file contents (4cdac4d8...).
      
      vfat does not support hardlinks, the file in the cache and in the store of
      r7 are thus independent.
      
      For the test to pass on vfat, we need to corrupt *both* the largefile in the
      usercache and in the store of r7. Corrupting only one of them is not sufficient.
      
      Fixes:
      
        --- /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t
        +++ /home/buildslave/mercurial/vfat_hg_tests__stable_/build/tests/test-largefiles.t.err
        @@ -997,9 +997,11 @@
           $ hg push -R r7 http://localhost:$HGPORT1
           pushing to http://localhost:$HGPORT1/
           searching for changes
        -  remote: largefiles: failed to put 4cdac4d8b084d0b599525cf732437fb337d422a8 into store: largefile contents do not match hash
        -  abort: remotestore: could not put $TESTTMP/r7/.hg/largefiles/4cdac4d8b084d0b599525cf732437fb337d422a8 to remote store http://localhost:$HGPORT1/ (glob)
        -  [255]
        +  searching for changes
        +  remote: adding changesets
        +  remote: adding manifests
        +  remote: adding file changes
        +  remote: added 2 changesets with 2 changes to 2 files
           $ rm -rf empty
      
         Push a largefiles repository to a served empty repository
      0cfece81e051
  16. Jul 21, 2012
  17. 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
  18. 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
    • Thomas Arendsen Hein's avatar
      dispatch: fix traceback when extension was tested with newer versions only · d1b49b02bc16
      Thomas Arendsen Hein authored
      The "worst" extension still is the one tested with the lowest tested version
      below the current version of Mercurial, but if an extension with was only
      tested with newer versions, it is considered a candidate for a bad extension,
      too. In this case extensions which have been tested with higher versions of
      Mercurial are considered better. This allows finding the oldest extension if
      ct can't be calculated correctly and therefore defaults to an empty tuple, and
      it involves less changes to the comparison logic during the current code
      freeze.
      d1b49b02bc16
    • Thomas Arendsen Hein's avatar
      test-extension.t: use fixed version string instead of current tag · 7af38fe1f829
      Thomas Arendsen Hein authored
      Currently tests break with the current tag being 2.3-rc and tags set by the
      user could affect this test, too.
      7af38fe1f829
    • Matt Mackall's avatar
      Added tag 2.3-rc for changeset a06e2681dd17 · 436cc9d017c6
      Matt Mackall authored
      436cc9d017c6
    • Matt Mackall's avatar
      merge default into stable for 2.3 code freeze · a06e2681dd17
      Matt Mackall authored
      2.3-rc
      a06e2681dd17
    • Matt Mackall's avatar
      merge with crew · 23b247234454
      Matt Mackall authored
      23b247234454
  19. Jul 18, 2012
    • Martin Geisler's avatar
      merge with stable · c315842cb25f
      Martin Geisler authored
      c315842cb25f
    • Martin Geisler's avatar
      windows: removed duplicate termwidth definition · 98823bd0d697
      Martin Geisler authored
      Changeset dbf91976f900 caused this when the "from win32 import *" line
      was replaced with explicit import statements: the wildcard import was
      at the bottom of the file and so windows.termwidth was overwritten by
      win32.termwidth as indented, but the new explicit import statements
      were at the top and so win32.termwidth got lost.
      
      With the switch to ctypes, win32 can always be imported and so the
      fallback termwidth in windows is no longer needed.
      98823bd0d697
  20. Jul 13, 2012
Loading