Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18145
largefiles: remove overly complex handling of ignored and unknown files
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:57 +0100] rev 18144
largefiles: introduce basic debugstate --large functionality
Very useful for debugging largefiles "performance" issues.
This is used for testing 03faf12fbee7.
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:57 +0100] rev 18143
util: fold ENOENT check into unlinkpath, controlled by new ignoremissing flag
Refactor a common pattern.
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:55:45 +0100] rev 18142
merge with stable
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18141
largefiles: don't walk through all ignored files
Problem: 'hg status' with largefiles enabled would walk through all the files
that .hgignore said should be ignored. That made it slow if a lot of files were
.hgignored or the cache was cold.
It seems like there was a reason to this, but other improvements has rendered
this unnecessary.
Solution: .hgignore is now only ignored when that is requested (--ignore).
This is a minimal 'stable' change. There is room for other improvement.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18140
largefiles revert: update lfdirstate with result from first cleanliness check
Largefiles revert do for some reason have two lfdirstates and lfdirstatestatus
invocations in one function. The result from the first lfdirstate check was
however not written back to the lfdirstate, and some files was thus checked
twice.
Mads Kiilerich <madski@unity3d.com> [Thu, 13 Dec 2012 19:19:06 +0100] rev 18139
largefiles status: update lfdirstate with result from cleanliness check
Problem: 'hg status' kept checking largefiles with an unknown state until some
other command wrote the updated dirstate.
Solution: Add missing lfdirstate.write().
Mads Kiilerich <madski@unity3d.com> [Fri, 28 Dec 2012 11:16:01 +0100] rev 18138
bundlerepo: don't return the peer without bundlerepo from getremotechanges
Problem:
getremotechanges would return the 'other' repo if nothing was incoming and
there thus wasn't any bundle to base the repo on. The 'other' could be a http
peer which only implement the functionality available over the http protocol.
Transplant could thus fail with
TypeError: argument of type 'httppeer' is not iterable
Solution:
Return the local repo instead of the remote peer if there is no reason to place
a bundlerepo on top of the local repo.