Fri, 04 Jan 2013 01:37:38 +0100 localrepo: drop `_cacheabletip` method
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 01:37:38 +0100] rev 18219
localrepo: drop `_cacheabletip` method It iss dead code now.
Fri, 04 Jan 2013 01:25:55 +0100 branchmap: drop `_cacheabletip` usage in `updatecache`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 01:25:55 +0100] rev 18218
branchmap: drop `_cacheabletip` usage in `updatecache` Nobody overwrite the `_cacheabletip` any more. We always update the cache for the whole repo and write it to disk (or at list try to). The `updatecache` code is simplied to remove the double phase logic associated with _cacheabletip.
Fri, 28 Dec 2012 03:42:21 +0100 mq: drop `_cacheabletip` usage
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 28 Dec 2012 03:42:21 +0100] rev 18217
mq: drop `_cacheabletip` usage Strip have dedicated work around to solve the same problem, strip is even a fraction faster without that thanks to simpler update process of the branchcache.
Fri, 28 Dec 2012 02:34:32 +0100 bundlerepo: drop use of `_cacheabletip`
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 28 Dec 2012 02:34:32 +0100] rev 18216
bundlerepo: drop use of `_cacheabletip` Now that bundlerepo use a read only VFS, we do not worry about what part of the branchmap is written back to disk. Nothing is written at all.
Fri, 28 Dec 2012 02:32:47 +0100 bundlerepo: enforce reading from core repo only
Pierre-Yves David <pierre-yves.david@logilab.fr> [Fri, 28 Dec 2012 02:32:47 +0100] rev 18215
bundlerepo: enforce reading from core repo only We do not want anything computed with the bundle overlay to be written back in the repo. Such write will likely contains invalid data. The short terms goal of this change is to drop use of `_cacheabletip` in bundle repo.
Fri, 04 Jan 2013 04:52:57 +0100 branchmap: ignore Abort error while writing cache
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 04:52:57 +0100] rev 18214
branchmap: ignore Abort error while writing cache Read only vfs can now raise Abort exception. Note that encoding.local are also a possible raiser.
Fri, 04 Jan 2013 01:07:25 +0100 vfs: add a read only vfs
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 04 Jan 2013 01:07:25 +0100] rev 18213
vfs: add a read only vfs This read only wrapper is intended to be used bundle repo. See follow up commit for details.
Sat, 22 Dec 2012 19:41:11 +0100 branchmap: read return None in case of failure
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 22 Dec 2012 19:41:11 +0100] rev 18212
branchmap: read return None in case of failure This makes a clear distinction between having read a valid cache on disk or not. This will help caches of various filtering level to collaborate.
Sat, 29 Dec 2012 00:40:18 +0100 clfilter: fallback to unfiltered version when linkrev point to filtered history
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 29 Dec 2012 00:40:18 +0100] rev 18211
clfilter: fallback to unfiltered version when linkrev point to filtered history On `filectx`, linkrev may point to any revision in the repository. When the repository is filtered this may lead to `filectx` trying to build `changectx` for filtered revision. In such case we fallback to creating `changectx` on the unfiltered version of the reposition. This fallback should not be an issue because `changectx` from `filectx` are not used in complex operation that care about filtering. It is complicated to work around the issue in a clearer way as code raising such `filectx` rarely have access to the repository directly. Linkrevs create a lot of issue with filtering. It is stored in revlog entry at creation time and never changed. Nothing prevent the changeset revision pointed to become filtered. Several bogus behavior emerge from such situation. Those bugs are complex to solve and not part of the current effort to install filtering. This changeset is simple hack that prevent plain crash in favor on minor misbehavior without visible effect. This "hack" is longly documented in to code itself to help people that would look at it in the future.
Mon, 24 Dec 2012 11:58:40 +0100 phases: prepare phase command for filtering
Pierre-Yves David <pierre-yves.david@logilab.fr> [Mon, 24 Dec 2012 11:58:40 +0100] rev 18210
phases: prepare phase command for filtering The phase command have some logic to report change made. We ensure this logic run unfiltered. With --force the command can change phase of a changeset for public to draft. Such change can lead to obsolescence marker to apply again and the changeset to be "hidden". If we do not run the logic unfiltered it could failed to fetch the phase of a newly filtered changeset.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip