Skip to content
Snippets Groups Projects
  1. Jan 29, 2013
  2. Jan 27, 2013
  3. Jan 29, 2013
  4. Jan 28, 2013
  5. Jan 25, 2013
  6. Jan 28, 2013
    • Mads Kiilerich's avatar
      largefiles: allow use of urls with #revision · f1700480
      Mads Kiilerich authored
      largefiles tried to create a peer directly with the specified url. That caused
        abort: unsupported URL component: "..."
      if a revision was specified in the url.
      
      The branch name do not matter for largefiles' use of remote peers. Largefiles
      will be shared among all branches anyway.
      f1700480
    • Mads Kiilerich's avatar
      largefiles: don't verify largefile hashes on servers when processing statlfile · a977b42d
      Mads Kiilerich authored
      When changesets referencing largefiles are pushed then the corresponding
      largefiles will be pushed too - unless the target already has them. The client
      will use statlfile to make sure it only sends largefiles that the target
      doesn't have. The server would however on every statlfile check that the
      content of the largefile had the expected hash. What should be cheap thus
      became an expensive operation that trashed the disk and the cache.
      
      Largefile hashes are already checked by putlfile before being stored on the
      server. A server should thus be able to keep its largefile store free of
      errors - even more than it can keep revlogs free of errors. Verification should
      happen when running 'hg verify' locally on the server. Rehashing every
      largefile on every remote stat is too expensive.
      
      Clients will also stat lfiles before downloading them. When the server verified
      the hash in stat it meant that it had to read the file twice to serve it.
      
      With this change the server will assume its own hashes are ok without checking
      them on every statlfile.
      
      Some consequences of this change:
      - in case of server side corruption the problem will be detected by the
        existing check on the client side - not on server side
      - clients that could upload an uncorrupted largefile when pushing will no
        longer magically heal the server (and break hardlinks) - a client will now
        only upload its uncorrupted files after the corrupted file has been removed
        on the server side
      - client side verify will no longer report corruption in files it doesn't have
      
      (Issue3123 discussed related problems - and how they have been fixed.)
      a977b42d
    • Mads Kiilerich's avatar
      tests: clarify test for pushing corrupted largefile · 7aacc114
      Mads Kiilerich authored
      The test no longer tested that the server prevented pushing a corrupt
      largefile. At the same time it tested what happened when the server already had
      a corrupt largefile.
      
      These two cases are now separated.
      7aacc114
    • Mads Kiilerich's avatar
      largefiles: verify all files in each revision and report errors in any revision · 1067a624
      Mads Kiilerich authored
      Verify used 'any' and would stop verifying after the first failure in each
      changeset.
      
      The exit code only reported the result from the last changeset.
      1067a624
    • Mads Kiilerich's avatar
      tests: better test coverage of largefiles localstore verify · 39cecda9
      Mads Kiilerich authored
      This demonstrates problems that will be fixed later.
      39cecda9
    • Mads Kiilerich's avatar
      largefiles: adapt remotestore._getfile to batched statlfile · d43823f9
      Mads Kiilerich authored
      9e1616307c4c introduced batching of statlfile, but not all codepaths got
      converted.
      
      _getfile gave _stat garbage and got garbage back. The garbage didn't match the
      expected error codes and was thus interpreted as success. It could thus end up
      trying to fetch a largefile that didn't exist.
      
      Instead we now pass _stat valid input and handle both correct and invalid
      output correctly.
      
      This makes the code work as intended ... but it would probably be better if it
      didn't abort on missing largefiles, just like it happened to do before.
      d43823f9
    • Mads Kiilerich's avatar
      largefiles: don't allow corruption to propagate after detection · ce5f529d
      Mads Kiilerich authored
      basestore.get uses util.atomictempfile when checking and receiving a new
      largefile ... but the close/discard logic was too clever for largefiles.
      Largefiles relied on being able to discard the file and thus prevent it from
      being written to the store. That was however too brittle. lfutil.copyandhash
      closes the infile after writing to it ... with a 'blecch' comment. The discard
      was thus a silent noop, and as a result of that corruption would be detected
      ... and then the corrupted files would be used anyway.
      
      Instead we now use a tmp file and rename or unlink it after validating it.
      
      A better solution should be implemented ... but not now.
      ce5f529d
    • Mads Kiilerich's avatar
      largefiles: adapt verify to batched remote statlfile (issue3780) · 6f219eb8
      Mads Kiilerich authored
      9e1616307c4c introduced batching of statlfile, but not all codepaths got
      converted.
      
      'hg verify' with a remotestore could thus crash with
        TypeError: 'builtin_function_or_method' object is not iterable
      
      Also, the 'hash' variable was used without assigning to it. Don't use variable
      names that collide with Python built-in functions. Instead we use 'expecthash'
      as in localstore.
      
      The tests for this issue covers an untested area. The tests happens to also
      reveal incorrect attempts at getting non-existing largefiles, bad server side
      handling of that, and corruption issues - all to be fixed later.
      6f219eb8
    • Mads Kiilerich's avatar
      largefiles: let wirestore._stat return stats as expected by remotestore verify · ed647c59
      Mads Kiilerich authored
      - preparing for fixing verify crash.
      ed647c59
  7. Jan 27, 2013
  8. Jan 25, 2013
  9. Jan 23, 2013
    • Katsunori FUJIWARA's avatar
      revset: evaluate sub expressions correctly (issue3775) · 692cbda1
      Katsunori FUJIWARA authored
      Before this patch, sub expression may return unexpected result, if it
      is joined with another expression by "or":
      
        - "^"/parentspec():
          "R or R^1" is not equal to "R^1 or R". the former returns only "R".
      
        - "~"/ancestorspec():
          "R or R~1" is not equal to "R~1 or R". the former returns only "R".
      
        - ":"/rangeset():
          "10 or (10 or 15):" is not equal to "(10 or 15): or 10". the
          former returns only 10 and 15 or grater (11 to 14 are not
          included).
      
      In "or"-ed expression "A or B", the "subset" passed to evaluation of
      "B" doesn't contain revisions gotten from evaluation of "A", for
      efficiency.
      
      In the other hand, "stringset()" fails to look corresponding revision
      for specified string/symbol up, if "subset" doesn't contain that
      revision.
      
      So, predicates looking revisions up indirectly should evaluate sub
      expressions of themselves not with passed "subset" but with "entire
      revisions in the repository", to prevent "stringset()" from unexpected
      failing to look symbols in them up.
      
      But predicates in above example don't so. For example, in the case of
      "R or R^1":
      
        1. "R^1" is evaluated with "subset" containing revisions other than
           "R", because "R" is already gotten by the former of "or"-ed
           expressions
      
        2. "parentspec()" evaluates "R" of "R^1" with such "subset"
      
        3. "stringset()" fails to look "R" up, because "R" is not contained
           in "subset"
      
        4. so, evaluation of "R^1" returns no revision
      
      This patch evaluates sub expressions for predicates above with "entire
      revisions in the repository".
      692cbda1
  10. Jan 19, 2013
  11. Jan 21, 2013
    • Kevin Bullock's avatar
      update: update to current bookmark if it moved out from under us (issue3682) · 2096e025
      Kevin Bullock authored
      If the current bookmark (the one listed in .hg/bookmarks.current)
      doesn't point to a parent of the working directory, e.g. if it was moved
      by a pull, use that as the update target instead of the tipmost
      descendent.
      
      A small predicate is (finally) added to the bookmarks module to check
      whether the current bookmark is also active.
      2096e025
    • Kevin Bullock's avatar
      test-bookmarks-pushpull.t: don't set bookmark active unnecessarily · 28b3d669
      Kevin Bullock authored
      The test in question doesn't have anything to do with having an active
      bookmark. This change makes the test change the two bookmarks it affects
      without making them active. It clears the way for adding a test for
      updating to an active bookmark that moved out from under us.
      28b3d669
  12. Jan 23, 2013
  13. Jan 22, 2013
    • Pierre-Yves David's avatar
      changectx: fix the handling of `tip` · a2e9fe93
      Pierre-Yves David authored
      We can not use `len(repo,changelog)`, it may be a filtered revision. We now use
      `repo,changelog.tip()` to fetch this information.
      
      The `tip` command is also fixed and tested
      
      Thanks goes to Idan Kamara for the initial report.
      a2e9fe93
    • Pierre-Yves David's avatar
      bisect: use changelog for iteration · 07771e23
      Pierre-Yves David authored
      With changelog filtering, we can not use xrange anymore. We have to use the
      changelog to do the iteration. This way, the changelog excludes filtered
      revision and we can safely use what we iterate over.
      
      Without this changes, bisect crash with a traceback if there is filtered
      revision in the repo. Tests have been updated.
      07771e23
  14. Jan 21, 2013
  15. Jan 22, 2013
Loading