Skip to content
Snippets Groups Projects
  1. Oct 08, 2012
  2. Oct 03, 2012
    • Idan Kamara's avatar
      check-code: replace heredocs in unified tests · cf204e9829f4
      Idan Kamara authored
      Heredocs are usually fed to other commands and
      shouldn't follow the standard conventions of shell
      commands.
      
      This restores the old behaviour of how heredocs
      were handled in old-style test files.
      cf204e9829f4
  3. Sep 19, 2012
  4. Oct 02, 2012
  5. Sep 30, 2012
  6. Oct 01, 2012
  7. Sep 26, 2012
  8. Sep 24, 2012
  9. Oct 01, 2012
  10. Sep 29, 2012
  11. Sep 27, 2012
    • Tomasz Kleczek's avatar
      lock: fixed race condition in trylock/testlock (issue3506) · 829919ef894a
      Tomasz Kleczek authored
      Suppose the following scenario:
      
      1. Process A takes the lock (e.g. on commit).
      2. Process B wants to grab the lock. Since lock file exists
         the exception is raised. In the catch block the testlock
         function is called.
      3. Process A releases the lock.
      4. Process B tries to read the lock file as a part of testlock
         function. This results in OSError (ENOENT) and since we're
         not inside the exception handler function this is propagated
         and aborts the whole operation.
      
      To fix this we now check in testlock function whether lock file
      actually exists and if not (i.e. if readlock fails) we just return.
      829919ef894a
  12. Sep 29, 2012
  13. Sep 20, 2012
    • Pierre-Yves David's avatar
      clfilter: introduce `filteredrevs` attribute on changelog · 5c89e7fa5bc2
      Pierre-Yves David authored
      This changeset allows changelog object to be "filtered". You can assign a set of
      revision numbers to the `changelog.filteredrevs` attributes. The changelog will
      then pretends these revision does not exists in this repo.
      
      A few methods need to be altered to achieve this behavior:
      
      - tip
      - __iter_
      - irevs
      - hasnode
      - headrevs
      
      For consistency and to help debugging, the following methods are altered too.
      Tests tend to show it's not necessary to alter them but have them raise proper
      exception helps to detect bad acces to filtered revisions.
      
      - rev
      - node
      - linkrev
      - parentrevs
      - flags
      
      The following methods would also need alteration for consistency purpose but
      this is non-trivial and not done yet.
      
      - nodemap
      - strip
      
      The C version of headrevs is not run if there is any revision to filter. It'll
      need a proper rewrite later to restore performance.
      5c89e7fa5bc2
  14. Sep 03, 2012
  15. Sep 20, 2012
  16. Sep 03, 2012
    • Pierre-Yves David's avatar
      clfilter: split `revlog.headrevs` C call from python code · e69274f8d444
      Pierre-Yves David authored
      Make the pure python implementation of headrevs available to derived classes. It
      is important because filtering logic applied by `revlog` derived class won't
      have effect on `index`. We want to be able to bypass this C call to implement
      our own.
      e69274f8d444
    • Pierre-Yves David's avatar
      clfilter: handle non contiguous iteration in `revlov.headrevs` · d686c6876ef6
      Pierre-Yves David authored
      This prepares changelog level filtering.  We can't assume that any revision can
      be heads because filtered revisions need to be excluded.
      
      New algorithm:
      - All revisions now start as "non heads",
      - every revision we iterate over is made candidate head,
      - parents of iterated revisions are definitely not head.
      
      Filtered revisions are never iterated over and never considered as candidate
      head.
      d686c6876ef6
  17. Sep 20, 2012
    • Pierre-Yves David's avatar
      clfilter: make the revlog class responsible of all its iteration · 474047947b8f
      Pierre-Yves David authored
      This prepares changelog level filtering. We need the algorithms used in revlog to
      work on a subset of revisions.  To achieve this, the use of explicit range of
      revision is banned. `range` and `xrange` calls are replaced by a `revlog.irevs`
      method. Filtered super class can then overwrite the `irevs` method to filter out
      revision.
      474047947b8f
  18. Sep 03, 2012
    • Pierre-Yves David's avatar
      clfilter: introduce a `hassecret` function · fdd0fc046cf1
      Pierre-Yves David authored
      We can only use copy clone if the cloned repo do not have any secret changeset.
      The current method for that is to run the "secret()" revset on the remote repo.
      But with proper filtering of hidden or unserved revision by the remote this
      revset won't return any revision even if some exist remotely. This changeset
      adds an explicit function to know if a repo have any secret revision or not.
      
      The other option would be to disable filtering for the query but I prefer the
      approach above, lighter both regarding code and performance.
      fdd0fc046cf1
    • Pierre-Yves David's avatar
      filter: `updatebranchcache` during `addchangegroup` instead of after lock · 9dbd5fa6d301
      Pierre-Yves David authored
      The forced recomputation of the branch cache was introduced by `ee317dbfb9d0`.
      Back there, `addchangegroup` did not handle any lock logic.
      
      Later `ee1ed6afac21` introduced lock logic to `addchangegroup`. Its description
      does not explain why the `updatebranchcache` call is made outside locking. I
      believe that the lock was released there because it fit well with the transaction
      release already in the code.
      
      Finally `926a06f7a353` moved all "unlocked" code of `addchangegroup` to an
      `repo._afterlock` callback.
      
      I do not think that the call to `updatebranchcache()` requires to be done
      outside locking. That may even be a bad idea to do so. Bringing this call back
      in the `addchangegroup` function makes the flow simpler and eases the following
      up changelog level filtering business.
      9dbd5fa6d301
  19. Aug 02, 2012
  20. Sep 25, 2012
    • Sergey Kishchenko's avatar
      resolve: commit the changes after each item resolve (issue3638) · 28c43957f8b4
      Sergey Kishchenko authored
      At the moment the resolve command doesn't save progress during the resolve process. In example if you try to resolve 100 conflicting files and interrupt the process (e.g., you close the external merge tool) after resolving 50 files you'll end up with 100 unresolved conflicts. Saving the progress helps a lot with long going merges. It's easy to achieve same behavior with simple script that calls resolve command for each unresolved file but it makes sense to make such behavior a default
      28c43957f8b4
  21. Sep 22, 2012
    • Katsunori FUJIWARA's avatar
      bookmarks: rename arguments/variables for source code readability · 2b6a795f19f7
      Katsunori FUJIWARA authored
      Before this patch, the argument bound to the source repository of
      incoming bookmarks for "bookmarks.diff()" is named as "remote".
      
      But in "hg outgoing" case, this argument is bound to local repository
      object.
      
      In addition to it, "local"/"remote" seem to mean not the direction of
      propagation of bookmarks, but just the location of cooperative
      repositories.
      
      To indicate the direction of propagation of bookmarks clearly on the
      source code, this patch uses "d(st)" and "s(rc)" combination instead
      of "l(ocal)" and "r(emote)" one.
      
        - "repo" and "remote" arguments are renamed to "dst" and "src"
        - "lmarks" and "rmarks" variables are renamed to "dmarsk" and "smarks"
      2b6a795f19f7
  22. Sep 27, 2012
    • Pierre-Yves David's avatar
      histedit: move `continue` logic into a dedicated function · 5b6c8f2fbda5
      Pierre-Yves David authored
      When histedit "continue", there is several complicated logic to apply in order to
      detect intermediate changeset and concluded pending operation.
      
      This changeset extract this logic in a dedicated function to lighten the main
      one. No alteration to the logic is done.
      5b6c8f2fbda5
  23. Sep 26, 2012
  24. Sep 27, 2012
  25. Jul 31, 2012
    • Matt Harbison's avatar
      largefiles: enable islfilesrepo() prior to a commit (issue3541) · ae57920ac188
      Matt Harbison authored
      Previously, even if a file was added with --large, 'hg addremove' or 'hg ci -A'
      would add all files (including the previously added large files) as normal
      files.  Only after a commit where a file was added with --large would subsequent
      adds or 'ci -A' take into account the minsize or the pattern configuration.
      This change more closely follows the help for largefiles, which mentions that
      'add --large' is required to enable the configuration, but doesn't mention the
      previously required commit.
      
      Also, if 'hg add --large' was performed and then 'hg forget <file>' (both before
      a largefile enabling commit), the forget command would error out saying
      '.hglf/<file> not tracked'.  This is also fixed.
      
      This reports that a repo is largefiles enabled as soon as a file is added with
      --large, which enables 'add', 'addremove' and 'ci -A' to honor the config
      settings before the first commit.  Note that prior to the next commit, if all
      largefiles are forgotten, the repository goes back to reporting the repo as not
      largefiles enabled.
      
      It makes no sense to handle this by adding a --large option to 'addremove',
      because then it would also be needed for 'commit', but only when '-A' is
      specified.  While this gets around the awkwardness of having to add a largefile,
      then commit it, and then addremove the other files when importing an existing
      codebase (and preserving that extra commit in permanent history), it does still
      require finding and manually adding one of the files as --large.  Therefore it
      is probably desirable to have a --large option for init as well.
      ae57920ac188
    • Matt Harbison's avatar
      largefiles: handle commit -A properly, after a --large commit (issue3542) · a02c1ffddae9
      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.
      a02c1ffddae9
  26. Sep 25, 2012
Loading