Sat, 30 Apr 2011 11:16:52 +0200 fix broken tests
Benoit Boissinot <benoit.boissinot@ens-lyon.org> [Sat, 30 Apr 2011 11:16:52 +0200] rev 14053
fix broken tests test-debugcomplete.t broken by 58e58406ed19 test-highlight.t broken by b24e5a708fad
Sat, 30 Apr 2011 03:44:31 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Sat, 30 Apr 2011 03:44:31 -0500] rev 14052
merge with stable
Fri, 29 Apr 2011 22:21:13 +0300 mq: add '.' and '..' to list of forbidden patch names stable
Idan Kamara <idankk86@gmail.com> [Fri, 29 Apr 2011 22:21:13 +0300] rev 14051
mq: add '.' and '..' to list of forbidden patch names When an empty string is being passed to normname it would return '.' causing checkfile() to always return that a patch with that name exists.
Fri, 04 Mar 2011 14:00:49 +0100 subrepo: handle svn tracked/unknown directory collisions stable
Patrick Mezard <pmezard@gmail.com> [Fri, 04 Mar 2011 14:00:49 +0100] rev 14050
subrepo: handle svn tracked/unknown directory collisions This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant and only works with svn >= 1.5 but the only alternative I can think of is to write our own purge command for subversion.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 +30000 tip