Skip to content
Snippets Groups Projects
  1. Jul 31, 2012
    • Matt Harbison's avatar
      largefiles: handle commit -A properly, after a --large commit (issue3542) · a02c1ffd
      Matt Harbison authored
      Previous to this, 'commit -A' would add as normal files, files that were already
      committed as largefiles, resulting in files being listed twice by 'status -A'.
      It also missed when (only) a largefile was deleted, even though status reported
      it as '!'.  This also has the side effect of properly reporting the state of the
      affected largefiles in the post commit hook after a remove that also affected a
      normal file (the largefiles used to be 'R', now are properly absent).
      
      Since scmutil.addremove() is called both by the ui command (after some trivial
      argument validation) and during the commit process when -A is specified, it
      seems like a more appropriate method to wrap than the addremove command.
      
      Currently, a repo is only enabled to use largefiles after an add that explicitly
      identifies some file as large, and a subsequent commit.  Therefore, this patch
      only changes behavior after such a largefile enabling commit.
      
      Note that in the test, if the final commit had a '-v', 'removing large8' would
      be printed twice.  Both of these originate in removelargefiles().  The first
      print is in verbose mode after traversing remove + forget, the second is because
      the '_isaddremove' attr is set and 'after' is not.
      a02c1ffd
  2. Sep 18, 2012
  3. Sep 09, 2012
    • Matt Harbison's avatar
      largefiles: delegate to the wrapped clone command · 6e2ab601
      Matt Harbison authored
      This allows the wrapped command's validation code to run (which is currently
      only to ensure 'noupdate' and 'updaterev' aren't both specified), the
      copy/pasted unpacking of hg.clone() args to be removed, and any future changes
      to the base command (however unlikely) to be inherited by largefiles.
      
      Unfortunately, the command override can't be swapped entirely for an hg.clone()
      override because the extra --all-largefiles arg needs to be injected.  It also
      isn't enough to call the wrapped clone command and leave the caching code after
      it, because the file caching code needs access to the destination repo, which is
      only available from hg.clone().  An alternative would be to use the dest path in
      the clone command override to re-obtain a reference to the repo.
      
      A slight deviation from the regular hg.clone() function is that the repo is NOT
      deleted if the caching fails, but that was also the previous behavior.  Maybe it
      should for consistency?
      6e2ab601
    • Matt Harbison's avatar
      largefiles: don't convert dest=None to dest=hg.defaultdest() in clone command · 3a1c6b64
      Matt Harbison authored
      A status message is output if hg.clone() determines the default destination
      because None was provided.  The previous code never passed None to hg.clone().
      3a1c6b64
    • Matt Harbison's avatar
      largefiles: restore caching of largefiles with 'clone -U --all-largefiles' · 56136786
      Matt Harbison authored
      This was broken when restoring normal -u and -U functionality.
      56136786
  4. Sep 08, 2012
    • Matt Harbison's avatar
      largefiles: restore normal 'clone -u' and 'clone -U' functionality · b7302d65
      Matt Harbison authored
      Previously, tip would be checked out regardless of the -u or -U parameter.  I'm
      not sure what the 'required for successful walkchangerevs' comment meant, but it
      appears to reference code which has since moved to downloadlfiles() in
      7d6a660ca151.  Perhaps it was to force caching when the -U parameter is given?
      The price of this change is that -U --all-largefiles won't cache anything.  That
      will be fixed next.
      
      Note that X + Y in the 'X largefiles updated, n removed' and 'Y additional
      largefiles cached' lines do not add up to the same values in these tests, but
      all of the largefiles have been downloaded.  The reason being that several
      largefiles have the same content (eb7338044 is pointed to by sub/large2, large3
      and sub/large4).  In the 'clone -u 1' operation, this largefile is cached to
      populate the working directory, even without --all-largefiles.  That means the
      file isn't downloaded again and cached in the rev where large3 and sub/large4
      both point to this file.  Downloading that one file in that one rev seems to be
      counted twice with 'clone -u 0'.  (Maybe it is also being downloaded twice?)
      b7302d65
  5. Sep 18, 2012
  6. Sep 17, 2012
  7. Sep 06, 2012
  8. Sep 10, 2012
  9. Sep 06, 2012
  10. Sep 11, 2012
  11. Sep 10, 2012
  12. Sep 03, 2012
  13. Aug 30, 2012
    • Pierre-Yves David's avatar
      amend: preserve phase of amended revision (issue3602) · bacde764
      Pierre-Yves David authored
      New commit from the amend process were created without any phase contraint. If
      the amended changeset had a different phase from it's parent, the phases data
      were lost.
      
      The changeset ensure the new commit are created in the same phase than the
      original changeset.
      bacde764
  14. Sep 06, 2012
  15. Sep 04, 2012
  16. Aug 31, 2012
    • Pierre-Yves David's avatar
      strip: fix revset usage (issue3604) · 63e9b073
      Pierre-Yves David authored
      The `repair` code builds a giant revset query instead of using the "%lr" idiom.
      It is inefficient and crash when the number of stripped changeset is too big.
      
      This changeset replaces the bad code by a better revset usage.
      63e9b073
  17. Aug 02, 2012
    • Pierre-Yves David's avatar
      mergetools.hgrc: set vimdiff to check=changed · 93bc65e9
      Pierre-Yves David authored
      The standard reaction in from of unexpected vimdiff is to ":quit". This will
      make vimdiff return a 0 status even if no merge were done at all.
      
      This change detect that nothing have been changed in vimdiff as a potential
      unresolved conflict.
      93bc65e9
  18. Aug 29, 2012
  19. Sep 01, 2012
  20. Aug 03, 2012
  21. Aug 15, 2012
  22. Aug 31, 2012
    • Pierre-Yves David's avatar
      strip: fix revset usage (issue3604) · 7c865f30
      Pierre-Yves David authored
      The `repair` code builds a giant revset query instead of using the "%lr" idiom.
      It is inefficient and crash when the number of stripped changeset is too big.
      
      This changeset replaces the bad code by a better revset usage.
      7c865f30
  23. Sep 01, 2012
  24. Aug 27, 2012
Loading