Skip to content
Snippets Groups Projects
  1. Mar 13, 2011
    • Alexander Solovyov's avatar
      graphmod: use revsets internally · 9966c95b
      Alexander Solovyov authored
      Thanks for the idea and most of the implementation to Klaus Koch
      
      Backs revisions() and filerevs() with DAG walker which can iterate through
      arbitrary list of revisions instead of strict one by one iteration from start to
      stop. When a gap occurs in a revisions (i.e. in file log), the next topological
      parent within the revset is searched and the connection to it is printed in the
      ascii graph.
      
      File graph can draw sometimes more connections than previous version, because
      graph is produced according to the revset, not according to a file's filelog.
      
      In case the graph contains several branches where the left parent is null, the
      graphs for each are printed sequentially, not in parallel as it was a case
      earlier (see for example the graph for README in hg-dev).
      9966c95b
  2. Apr 29, 2011
  3. Apr 24, 2011
    • Adrian Buehlmann's avatar
      changegroup: do not count closed new heads (issue2697) · 90d997a8
      Adrian Buehlmann authored
      If a closed head gets pulled, we currently see (example):
      
        $ hg pull
        pulling from $TESTTMP/repo2
        searching for changes
        adding changesets
        adding manifests
        adding file changes
        added 2 changesets with 1 changes to 1 files (+1 heads)
        (run 'hg heads' to see heads, 'hg merge' to merge)
      
      A subsequent 'hg heads' doesn't show that head because it is closed.
      
      This patch improves the UI response texts for that same use case to:
      
        $ hg pull
        pulling from $TESTTMP/repo2
        searching for changes
        adding changesets
        adding manifests
        adding file changes
        added 2 changesets with 1 changes to 1 files
        (run 'hg update' to get a working copy)
      
      That is, the part "(+1 heads)" is not shown in that case any longer.
      90d997a8
  4. Apr 29, 2011
  5. Mar 13, 2011
  6. Apr 29, 2011
  7. Apr 26, 2011
  8. Apr 25, 2011
  9. Apr 26, 2011
  10. Apr 25, 2011
  11. Apr 24, 2011
    • Greg Ward's avatar
    • Greg Ward's avatar
      atomictempfile: avoid infinite recursion in __del__(). · d764463b
      Greg Ward authored
      The problem is that a programmer using atomictempfile directly can
      make an innocent everyday mistake -- not enough args to the
      constructor -- which escalates badly.  You would expect a simple
      TypeError crash in that case, but you actually get an infinite
      recursion that is surprisingly difficult to kill: it happens between
      __del__() and __getattr__(), and Python does not handle infinite
      recursion from __del__() well.
      
      The fix is to not implement __getattr__(), but instead assign instance
      attributes for the methods we wish to delegate to the builtin file
      type: write() and fileno(). I've audited mercurial.* and hgext.* and
      found no users of atomictempfile using methods other than write() and
      rename(). I audited third-party extensions and found one (snap)
      passing an atomictempfile to util.fstat(), so I also threw in
      fileno().
      
      The last time I submitted a similar patch, Matt proposed that we make
      atomictempfile a subclass of file instead of wrapping it. Rejected on
      grounds of unnecessary complexity: for one thing, it would make the
      Windows implementation of posixfile quite a bit more complex. It would
      have to become a subclass of file rather than a simple function -- but
      since it's written in C, this is non-obvious and non-trivial.
      Furthermore, there's nothing wrong with wrapping objects and
      delegating methods: it's a well-established pattern that works just
      fine in many cases. Subclassing is not the answer to all of life's
      problems.
      d764463b
  12. Apr 25, 2011
  13. Apr 22, 2011
  14. Apr 24, 2011
Loading