- Mar 13, 2011
-
-
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).
-
- Apr 29, 2011
-
-
Augie Fackler authored
It should be possible to do better than this with 'svn switch', but the logic required woud be significantly more complex. Until someone needs the performance improvements of using switch, we'll just use the same strategy for everything.
-
Alexander Solovyov authored
-
Idan Kamara authored
This won't risk losing the undo file when the error was something other than file not found
-
Idan Kamara authored
-
Idan Kamara authored
regressed around ec4ae5727f07
-
- Apr 24, 2011
-
-
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.
-
- Apr 29, 2011
-
-
Benoit Boissinot authored
-
Augie Fackler authored
-
Augie Fackler authored
We only verify the extension runs and that verify passes at the end as constructing a test repository that would result in a shrink would be nontrivial.
-
Augie Fackler authored
-
Augie Fackler authored
-
Augie Fackler authored
-
Augie Fackler authored
-
Augie Fackler authored
-
- Mar 13, 2011
-
-
Benoit Boissinot authored
-
- Apr 29, 2011
-
-
Patrick Mezard authored
-
Thomas Arendsen Hein authored
-
Thomas Arendsen Hein authored
I just had: transferred 606 bytes in 2.9 seconds (211 bytes/sec)
-
Patrick Mezard authored
-
Patrick Mezard authored
-
- Apr 26, 2011
-
-
Matt Mackall authored
-
- Apr 25, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Apr 26, 2011
-
-
Patrick Mezard authored
-
Martin Geisler authored
-
Martin Geisler authored
-
Martin Geisler authored
-
- Apr 25, 2011
-
-
Patrick Mezard authored
-
Patrick Mezard authored
-
Steven Brown authored
This can be used to test that the client and server both fall back to the previous wire protocol when the capability is not supported. It is currently used by test-push-http.t and I plan to use it for the HTTP long argument support tests.
-
Pierre-Yves David authored
When mq status entry referencing a patches that is not in series `hg qfinish -a` used to issue a traceback. This states is inconsistent but might happen regularly when people misuse hg up -mq. This changeset prevent hg from crashing. The faulty entry is finished anyway and a warning is issued.
-
Idan Kamara authored
-
- Apr 24, 2011
-
-
Greg Ward authored
-
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.
-
- Apr 25, 2011
-
-
Patrick Mezard authored
-
- Apr 22, 2011
-
-
Idan Kamara authored
-
Idan Kamara authored
-
- Apr 24, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-