Mon, 08 Sep 2014 20:57:44 +0200 parsers: avoid signed/unsigned comparison mismatch
Henrik Stuart <hg@hstuart.dk> [Mon, 08 Sep 2014 20:57:44 +0200] rev 22403
parsers: avoid signed/unsigned comparison mismatch Based on warning from Microsoft Visual C++ 2008.
Mon, 08 Sep 2014 20:22:10 +0200 parsers: use correct type for file offset
Henrik Stuart <hg@hstuart.dk> [Mon, 08 Sep 2014 20:22:10 +0200] rev 22402
parsers: use correct type for file offset Now using Py_ssize_t instead of long to denote offset in file whose length is already measured using Py_ssize_t. Length and offset are now consistent. Based on warning from Microsoft Visual C++ 2008.
Mon, 08 Sep 2014 20:20:17 +0200 parsers: ensure correct return type for inline_scan
Henrik Stuart <hg@hstuart.dk> [Mon, 08 Sep 2014 20:20:17 +0200] rev 22401
parsers: ensure correct return type for inline_scan The returned data type for inline_scan should be Py_ssize_t rather than long. Based on warning from Microsoft Visual C++ 2008.
Thu, 11 Sep 2014 12:05:23 -0500 parsers: fix typing issue when constructing Python integer object
Henrik Stuart <hg@hstuart.dk> [Thu, 11 Sep 2014 12:05:23 -0500] rev 22400
parsers: fix typing issue when constructing Python integer object The passed variable is a Py_ssize_t, not a long, and consequently should use PyInt_FromSsize_t rather than PyInt-FromLong. Fixed based on warning from Microsoft Visual C++ 2008.
Mon, 08 Sep 2014 20:06:52 +0200 parsers: use bitmask type consistently in find_gca_candidates
Henrik Stuart <hg@hstuart.dk> [Mon, 08 Sep 2014 20:06:52 +0200] rev 22399
parsers: use bitmask type consistently in find_gca_candidates Normalized type usage in find_gca_candidates triggered by warning from Microsoft Visual C++ 2008.
Sat, 30 Aug 2014 02:10:29 +0200 revert: drop `lexist` check in the backup logic
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 Aug 2014 02:10:29 +0200] rev 22398
revert: drop `lexist` check in the backup logic We are no longer trying to backup files that do not exist on disk. This check can be safely dropped.
Sat, 30 Aug 2014 02:09:53 +0200 revert: distinguish between deleted file and locally modified
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 Aug 2014 02:09:53 +0200] rev 22397
revert: distinguish between deleted file and locally modified Locally modified needs a backup while a deleted file cannot be backed up because there is no file to backup.
Sat, 30 Aug 2014 02:00:20 +0200 revert: detect unknown files in the same path as files marked as removed
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 Aug 2014 02:00:20 +0200] rev 22396
revert: detect unknown files in the same path as files marked as removed Such unknown files may need to be backed up. Having them identified beforehand will help simplify the backup logic. We now use different sets with different backup strategies.
Sat, 30 Aug 2014 01:52:08 +0200 revert: cache working context in a variable
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 30 Aug 2014 01:52:08 +0200] rev 22395
revert: cache working context in a variable During the silicon age, humans on planet Earth discovered the use of variables. This marvelous invention let them improve both code readability and performance.
Wed, 10 Sep 2014 14:42:52 +0100 obsolete: properly drop 'date' from metadata
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 10 Sep 2014 14:42:52 +0100] rev 22394
obsolete: properly drop 'date' from metadata Mistakes were made while resolving rebase conflicts in 4bc96685a40c. This led to 'date' being preserved in metadata when reading markers from a binary stream. As a result, some known markers were seen as "new" when pulling. I noticed it because a no-op pulls from main added about 600 duplicated markers to my obsstore (for each pull). I do not believe we need to perform any specific action to actively de-duplicates existing obsstore. After this fix, duplicated markers will no be propagated and the few affected repositories can probably deal with duplication (or people can repull the obsstore from a clone). As a side effect, we decode metadata only once, reducing the impact of the hack in fm0 to store extra important data (parents and date).
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip