Skip to content
Snippets Groups Projects
  1. Oct 31, 2012
  2. Oct 30, 2012
  3. Oct 23, 2012
  4. Oct 29, 2012
  5. Oct 28, 2012
  6. Oct 24, 2012
    • Bryan O'Sullivan's avatar
    • Matt Harbison's avatar
      largefiles: don't copy largefiles from working dir to the store while converting · d1d01402
      Matt Harbison authored
      Previously, if one or more largefiles for a repo being converted were not in the
      usercache, the convert would abort with a reference to the largefile being
      missing (as opposed to the previous patch, where the standin was referenced as
      missing).  This is because commitctx() tries to copy all largefiles to the
      local store, first from the user cache, and if the file isn't found there, from
      the working directory.  No files will exist in the working directory during a
      convert, however.  It is not sufficient to force the source repo to be local
      before proceeding, because clone and pull do not download largefiles by default.
      
      This is slightly less than ideal because while the conversion will now complete,
      it won't be possible to update to revs with missing largefiles unless the user
      intervenes manually, because there is no default path pointing back to the
      source repo.  Ideally these files would be cached during the conversion.
      
      This check could have been done in reposetup.commitctx() instead, but this
      ensures the local store directory is created, which is necessary to enable the
      standin matcher.
      
      The rm -> 'rm -f' change in the test is to temporarily suppress an error
      clearing the cache- as noted, the cache is is not repopulated during convert.
      When that is fixed, this can be changed back and the verification errors will
      disappear too.
      d1d01402
    • Matt Harbison's avatar
      largefiles: respect the rev when reading standins in copytostore() (issue3630) · 92bbb21d
      Matt Harbison authored
      When the rev isn't specified, the standin for the working copy gets read.  But
      convert doesn't update the working copy for each cset it processes, so there is
      no standin and the 'hg convert' would abort complaining about the standin being
      missing.
      
      Note that if the largefile is not in the user cache, 'hg convert' complains
      about the largefile itself missing from the destination repo.
      92bbb21d
  7. Oct 09, 2012
  8. Oct 04, 2012
  9. Jul 28, 2012
  10. Sep 29, 2012
    • Katsunori FUJIWARA's avatar
      subrepo: isolate configuration between each repositories in subrepo tree · 573bec4a
      Katsunori FUJIWARA authored
      Before this patch, repository local configurations are not isolated
      between repositories in subrepo tree, because "localrepository"
      objects for each subrepositories are created with "ui" instance of the
      parent of each ones.
      
      So, local configuration of the parent or higher repositories are
      visible also in children or lower ones.
      
      This patch uses "baseui" instead of "ui" to create repository object:
      the former contains only global configuration.
      
      This patch also copies 'ui.commitsubrepos' configuration to commit
      recursively in subrepo tree, because it may be set in not
      "repo.baseui" but "repo.ui".
      573bec4a
  11. Oct 27, 2012
  12. Oct 26, 2012
  13. Oct 25, 2012
    • Pierre-Yves David's avatar
      bookmark: prevent crashing when a successor is unknown locally (issue3680) · daf32ebf
      Pierre-Yves David authored
      The `%ln` revset substitution does not accept unknown node. We prune unknown
      node from potential successors before computing descendants.
      
      This have no impact on the result of this function.
      
      - Descendants of unknown changeset as unknown,
      - all successors of unknown changesets are already return by the call who
        returned those same unknown changesets,
      - unknown changesets are never a valid destination for a bookmark.
      daf32ebf
    • Pierre-Yves David's avatar
      bookmark: complexity pull-push test to have deeper tree · d044a762
      Pierre-Yves David authored
      This changeset only touch test.
      
      The previous test was correct, it tested that the successors of an old bookmark
      position was seen as a valid destination for bookmark.
      
      However, a newer version is made for two reason:
      
      (1) The new test check further. It check that the descendant of the successors
          is a valid destination
      
      (2) An ever more complexe test is needed to validate a future fix to issue 3680
          Splitting complexification of the test and actual bugfix help to reduce the
          noise in the bugfix changeset. Issue 3680 is NOT fixed by this changeset.
      d044a762
  14. Oct 24, 2012
  15. Oct 23, 2012
    • Katsunori FUJIWARA's avatar
      test: add test for the issue introduced by e410be860393 (issue3669) · acd4577a
      Katsunori FUJIWARA authored
      e410be860393 (released as Mercurial 2.3) introduced the issue that the
      revset program started with 40 hexadecimal letters caused unexpected
      result at "hg log" execution.
      
      This issue was already fixed by bde1185f406c (released as 2.3.1), but
      there is no test to examine whether this issue is certainly fixed or
      not: no test fails even if bde1185f406c is backed out.
      
      This patch adds test for this issue.
      
      Added test is also confirmed to fail, when it is tested against:
      
        - Mercurial 2.3, or
        - Mercurial 2.3.1 or later with backing bde1185f406c out
      acd4577a
  16. Oct 19, 2012
  17. Oct 23, 2012
  18. Oct 21, 2012
  19. Oct 22, 2012
  20. Oct 21, 2012
    • Matt Harbison's avatar
      largefiles: use 'default' instead of 'default-push' when pulling (issue3584) · 1e4eb1fa
      Matt Harbison authored
      This only applies to downloading largefiles, and only when no source for the
      pull is explicitly provided.  The repository itself was properly being pulled
      via 'default' previously.
      
      Using --all-largefiles is not necessary on a bare pull to test this (this
      existing test is merely a convenience), but it is required to test pulling on
      the rebase path.
      
      Note that the errors generated in the --rebase case are because the repo
      specified doesn't have the largefiles in its cache (though they are in the user
      cache), so the errors are misleading.  Specifying --all-largefiles when cloning
      to 'b' fixes this, but instead of errors, it reports caching only 5 largefiles
      instead of the 9 that come up missing.  Likely this is because the largefile
      download procedure tries to download missing files for each rev, and some of the
      files have standins in more than one rev that gets pulled.
      1e4eb1fa
  21. Oct 22, 2012
  22. Oct 19, 2012
Loading