4d3ce1646dfcfe7942f3dc7aa2e067c43fb9a644: context: use "vfs.lstat()" instead of "os.lstat()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19901
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
context: use "vfs.lstat()" instead of "os.lstat()"
7c21e3398931acaebb200622f5385d1dea1351b1: context: use "vfs.lstat()" instead of "os.lstat()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19900
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
context: use "vfs.lstat()" instead of "os.lstat()" This patch also changes paths added to "rejected" list from full path (referred by "p") to relative one (referred by "f"), when type of target path is neither file nor symlink. This change should be reasonable, because the path added to "rejected" list is relative one, when "OSError" is raised at "lstat()".
8c3dcbbfb5deaa2385e5166542a5c8a6fbd6df81: changelog: use "vfs.fstat()" instead of "util.fstat()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19899
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
changelog: use "vfs.fstat()" instead of "util.fstat()" Just invoking "os.fstat()" with "file.fileno()" doesn't require non ANSI file API, because filename is not used for invocation of "os.fstat()". But "util.fstat()" should invoke "os.stat()" with "fp.name", if file object doesn't have "fileno()" method for portability, and "fp.name" may cause invocation of non ANSI file API. So, this patch makes the constructor of appender class invoke "util.fstat()" via vfs, to encapsulate filename handling.
3f92e749d381575a5313963919b924b8bc64a178: changelog: use "vfs.rename()" instead of "util.rename()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19898
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
changelog: use "vfs.rename()" instead of "util.rename()"
896a4568def7e8ac61660cf72ca92235fbcef4a6: vfs: add "open()" for newly added code paths which open files via vfs
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19897
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
vfs: add "open()" for newly added code paths which open files via vfs This patch replaces "open()" by own "__call__()" defined in derived classes at the first invocation, for efficiency of succeeding invocations.
af03279c766a4c3d21129d466271ca12085f6b97: bookmarks: use "vfs.utime()" instead of "os.utime()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19896
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
bookmarks: use "vfs.utime()" instead of "os.utime()"
37c0d93fb16657010df512b0bee84c74cd65020e: bookmarks: use "vfs.unlink()" instead of "util.unlink()"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> - Tue, 15 Oct 2013 00:51:04 +0900 - rev 19895
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
bookmarks: use "vfs.unlink()" instead of "util.unlink()"
df91e2df6ba3824c3dba13c7d1a54646adfcc0e6: cmdutil: use None as default value for "function pointer" instead of False
Mads Kiilerich <madski@unity3d.com> - Thu, 03 Oct 2013 18:01:21 +0200 - rev 19894
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
cmdutil: use None as default value for "function pointer" instead of False Less type confusion.
dc4edca39e41de9f1b16f256954b192b762cc9b9: graft: make skip messages more helpful
Mads Kiilerich <madski@unity3d.com> - Thu, 03 Oct 2013 18:01:21 +0200 - rev 19893
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
graft: make skip messages more helpful This makes it possible for the user to understand and accept or work around what is happening.
77872b002e73fcea7c69612544acee36137fdc70: convert: update source shamap when using filemap, just as when not using filemap
Mads Kiilerich <madski@unity3d.com> - Thu, 03 Oct 2013 18:01:21 +0200 - rev 19892
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
convert: update source shamap when using filemap, just as when not using filemap The reverse mapping was introduced in 2147a734dcf9 to make roundtrip conversions possible ... but it did not work when using filemap. Roundtrips with filemaps will of course only work flawlessly if inverse mappings are used. Especially, if a lossy convert mapping is used in one direction, then only linear lines of development can be converted in the other direction. With this constraint convert will do the right thing by assuming that excluded files haven't been changed.) A test case with general coverage of hg-hg roundtrips with filemap is added. (There a cases where adding records of converted revisions to the shamap in the source repository doesn't work - especially when converting the same repo to several other repos and back. It would arguably be better if convert only updated the shamaps in the target repo but read shamaps from both the source and and target repo ... but that is a different story. Making the stuff we have work consistently is step forward no matter what.)
e271970b98216098c1cb0c71ae1076d7ac0ad8ee: convert: introduce hg.revs to replace hg.startrev and --rev with a revset
Mads Kiilerich <madski@unity3d.com> - Sat, 20 Jul 2013 00:43:08 +0200 - rev 19891
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
convert: introduce hg.revs to replace hg.startrev and --rev with a revset The existing knobs for controlling which revisions to convert were often insufficient. Revsets is a shiny hammer that provides a better solution. Revsets has been introduced in --rev handling in a lot of other places while being more or less backwards compatible. Doing the same here would be a much more elegant ... but that would unfortunately not work in this case. "--rev 7" used to mean revision 0 to 7 - it would be an unacceptable change if it suddenly just meant revision 7. Instead we introduce a new configuration setting. It will only work for Mercurial repositories so adding a new commandline option for it would not be a nice solution. There is no way to use the fancy deprecation markup for configuration settings so we just remove the documentation of hg.startrev.
9057855d87490cc77a0f9acc42e8bd1718c0c55f: convert: refactor head calculation for hg sources
Mads Kiilerich <madski@unity3d.com> - Thu, 03 Oct 2013 18:01:21 +0200 - rev 19890
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
convert: refactor head calculation for hg sources
3828b3e09462132d205db72bffa4bc7922d3b96f: convert: remove unused and incorrect default handling for revmapfile
Mads Kiilerich <madski@unity3d.com> - Fri, 19 Jul 2013 14:20:11 +0200 - rev 19889
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
convert: remove unused and incorrect default handling for revmapfile destc is not a string and can thus not be os.path.join'ed. Convert would crash if we ended up there ... but we wouldn't because both the sinks (hg and subversion) sinks implement .revmapfile and "never" throws exceptions.
1b2f9d36953e6ed384a044c1e73cb3a1aa072004: generaldelta: fix test
Wojciech Lopata <lopek@fb.com> - Mon, 30 Sep 2013 18:27:42 -0700 - rev 19888
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
generaldelta: fix test
dd7c294365f0f0e50aa1a215a64c63fb8accff59: shelve: fix dirstate corruption during unshelve (issue4055)
Durham Goode <durham@fb.com> - Fri, 11 Oct 2013 17:19:40 -0700 - rev 19887
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
shelve: fix dirstate corruption during unshelve (issue4055) If you shelved on top of commit A, then rebased A to @ and unshelved, any file changed in A would appear as modified in hg status despite the contents not having changed. The fix is to use dirstate.setparents() instead of doing it manually. This will be a little slower since it has to iterate through everything in the dirstate instead of only what's in the mergestate, but this will be more correct since the mergestate did not include files which were merged but had no conflict. The tests also had several bad dirstate's hardcoded in them. This change updates the tests appropriately and adds a new test to cover this specific rebase case.
e828975722c8ff632f08cbeb84ec184da2952823: merge with stable
Matt Mackall <mpm@selenic.com> - Wed, 09 Oct 2013 14:15:34 -0700 - rev 19886
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
merge with stable
6cc696179869b7cafda6321221840f3f3d0e6748: shelve: only save mq state if enabled
Sean Farley <sean.michael.farley@gmail.com> - Wed, 09 Oct 2013 14:15:20 -0700 - rev 19885
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
shelve: only save mq state if enabled Test coverage has been added.
fc3fbca350853591c4d78bb7a15059533afdfa6f: changegroup: don't run changegroup hooks if nodes are gone
Durham Goode <durham@fb.com> - Mon, 07 Oct 2013 11:45:01 -0700 - rev 19884
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
changegroup: don't run changegroup hooks if nodes are gone The changegroup hook runs when the repo lock is released, but it's possible that multiple transactions have happened during that single lock and therefore the commits the hook was for may be gone. This is the case in the shelve extension where it adds a commit and strips it in the same lock but different transactions (which results in warning messages during unshelve on hgsubversion repos). A real fix would be to attach the hook to the transaction instead, but that might have unknown consequences. Since we're this close to code-freeze, this fix just prevents the hook from running if the commit disappeared.
904061628dc42c88c1c3617a884ae23b7ace5dfd: hgweb: add escaping of tags and bookmarks in graph view stable
Matt Mackall <mpm@selenic.com> - Wed, 09 Oct 2013 12:02:32 -0700 - rev 19883
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
hgweb: add escaping of tags and bookmarks in graph view
55c763926a28982ce0003078fb38c6db58bca8aa: json: add more paranoid escaping stable
Matt Mackall <mpm@selenic.com> - Wed, 09 Oct 2013 11:50:19 -0700 - rev 19882
Push 1 by gszorc@mozilla.com at Wed, 18 Mar 2015 16:34:57 +0000
json: add more paranoid escaping
(0) -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 tip