Thu, 13 Nov 2014 11:17:09 +0000 transaction: support cache file in backupentries
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 13 Nov 2014 11:17:09 +0000] rev 23312
transaction: support cache file in backupentries We do not want to abort if anything wrong happen while handling a cache file. Cache file have way to be invalidated and if old/bad version stay no misbehavior will happen. Proper value will eventually be computed and the wrong will be righten. This changeset use the transaction reporter (usually writing on stderr) to write details about failed cache handling. This will only apply to write operation using a transaction. The usual update during read only operation will stay a debug message. I was on the way to bring these message back to debug level when I realised it could be a feature. People with write access to the repository are likely to have the power to fix error related to cache (and it is valuable to fix them). So let the things as is for now.
Fri, 17 Oct 2014 21:04:35 -0700 transaction: use the location value when doing backup
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 21:04:35 -0700] rev 23311
transaction: use the location value when doing backup We finally use the 'location' value coupled with the 'vfsmap' to restore backup for the right file.
Fri, 17 Oct 2014 20:49:39 -0700 transaction: pass a vfs map to the transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 20:49:39 -0700] rev 23310
transaction: pass a vfs map to the transaction The goal is to allow access to file outside ofthe store directory from the transaction. The obvious target are the `bookmarks` file. But we can envision usage for cache too. We keep passing a main opener explicitly because a lot of code rely on this default opener. The main opener (operating on store) is using an empty key ''.
Wed, 05 Nov 2014 01:52:46 +0000 transaction: change the on disk format for backupentries
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:52:46 +0000] rev 23309
transaction: change the on disk format for backupentries We need to store new data to improve the current transaction logic: - location: We want to generate and backup file outside of the 'store' (eg: bookmarks, or various cache files). This requires knowing and preserving where each file is located. The value of this new field is a string. It will be used as a key for a vfs mapping. - cache: We would like to handle cache file in the transaction code. This Will help to have cache consistent with the repository state and avoid performance issue on big repository like Mozilla. However, failure to handle cache file should not result in a transaction failure. We add a new field that carry this information. The value is boolean, A True value mean any error while handling this file can be ignored. Those two mechanisms are not implemented yet, but they are now persisted in the on disk file. Support for new mechanisms is coming in later changeset. We update the file format now and will introduce the new features in later changeset. The format version is set to 0 until we actually support the new feature. This will prevent misunderstanding between incomplete and final client. Support for reading both version 1 and (future) version 2 could be achieved (using default value when reading version 1) but has not been seen as necessary for now.
Thu, 13 Nov 2014 15:47:15 -0500 silenttestrunner: add environment variable to make tests noisy again
Augie Fackler <augie@google.com> [Thu, 13 Nov 2014 15:47:15 -0500] rev 23308
silenttestrunner: add environment variable to make tests noisy again As I've been working on complicated extension code it's been handy to be able to get standard unittest verbose output so I can find crashers more efficiently.
Fri, 14 Nov 2014 05:58:59 -0800 largefiles: update comments to refer to the right overridden method
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Nov 2014 05:58:59 -0800] rev 23307
largefiles: update comments to refer to the right overridden method This cleans up leftovers from b228ad1f79d7 (largefiles: override calculateupdates instead of manifestmerge, 2014-03-02).
Thu, 13 Nov 2014 21:36:38 -0800 revlog: cache chain info after calculating it for a rev (issue4452)
Siddharth Agarwal <sid0@fb.com> [Thu, 13 Nov 2014 21:36:38 -0800] rev 23306
revlog: cache chain info after calculating it for a rev (issue4452) This dumb cache works surprisingly well: on a repository with typical delta chains ~50k in length, unbundling a linear series of 5000 revisions (changelogs and manifests only) went from 60 seconds to 3.
Wed, 22 Oct 2014 21:38:30 -0700 manifest: add matches() method
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Oct 2014 21:38:30 -0700] rev 23305
manifest: add matches() method Move the code in context._manifestmatches() into a new manifest.matches(). It's a natural place for the code to live and it allows other callers to easily use it. It should also make it easier to optimize the new method in alternative implementations of the manifest (same reasoning as with manifest.diff()).
Wed, 12 Nov 2014 22:20:36 -0800 context.status: pass status tuple into _buildstatus
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 22:20:36 -0800] rev 23304
context.status: pass status tuple into _buildstatus By passing a status tuple (instead of the current list), we can access the status fields by name and make it a little more readable.
Wed, 12 Nov 2014 22:07:31 -0800 context.status: avoid de- and reconstructing status tuple
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 22:07:31 -0800] rev 23303
context.status: avoid de- and reconstructing status tuple We can just modify the status tuple we got from dirstate.status() instead of deconstructing it and constructing a new instance, thereby simplifying the code a little.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip