Fri, 14 Nov 2014 09:33:28 -0800 manifestmerge: use already existing fl2 synonym for m2.flags(f)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Nov 2014 09:33:28 -0800] rev 23320
manifestmerge: use already existing fl2 synonym for m2.flags(f) Probably not a noticeable performance gain, but shortens the code slightly.
Thu, 13 Nov 2014 23:12:15 -0800 merge: drop underscore prefix from _checkunknown()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 13 Nov 2014 23:12:15 -0800] rev 23319
merge: drop underscore prefix from _checkunknown() The method has been called from commands.py since 3eab42088be4 (update: just merge unknown file collisions, 2012-02-09), so drop the underscore prefix that suggests that it's private.
Wed, 12 Nov 2014 14:47:48 +0000 transaction: drop special handling for phases and bookmarks generation
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 12 Nov 2014 14:47:48 +0000] rev 23318
transaction: drop special handling for phases and bookmarks generation We are still doing double backups, but now that we have proper location handling this is less of an issue. Dropping this simplifies the code before we add some pending-related logic. This also ensures we actually test the new 'location' mechanism.
Fri, 17 Oct 2014 20:53:42 -0700 transaction: use 'location' instead of 'vfs' objects for file generation
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 17 Oct 2014 20:53:42 -0700] rev 23317
transaction: use 'location' instead of 'vfs' objects for file generation The argument is now a location name. The location must be present in the 'vfsmap' provided to the transaction at creation time.
Wed, 05 Nov 2014 01:59:32 +0000 transaction: use 'location' instead of 'vfs' in the addbackup method
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 01:59:32 +0000] rev 23316
transaction: use 'location' instead of 'vfs' in the addbackup method This unlock the backup of file outside of store (eg: bookmarks).
Fri, 14 Nov 2014 00:14:23 +0000 addbackup: handle file in subdirectory
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Nov 2014 00:14:23 +0000] rev 23315
addbackup: handle file in subdirectory The current naming scheme ('journal.backups.<file>') resulted is bad directory name when 'file' was in a subdirectory. We now extract the directory name and create the backupfile within it. We plan to use file in a subdirectory for cachefile.
Fri, 14 Nov 2014 14:54:55 +0000 addbackup: use the vfs for the backup destination too
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Nov 2014 14:54:55 +0000] rev 23314
addbackup: use the vfs for the backup destination too The backup file location was always computed using the opener, bypassing the 'location' setting. (And making the feature broken.)
Thu, 13 Nov 2014 11:17:36 +0000 transaction: set backupentries version to proper value
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 13 Nov 2014 11:17:36 +0000] rev 23313
transaction: set backupentries version to proper value Now that all mechanisms are in place, we can advertise it with a proper new version.
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.
Wed, 12 Nov 2014 16:51:11 -0800 context.status: make _dirstatestatus() return an status tuple
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 16:51:11 -0800] rev 23302
context.status: make _dirstatestatus() return an status tuple Letting _dirstatestatus() return an scmutil.status instance also means that _buildstatus() will always return such an instance, so we can remove the conversion from the call sites.
Wed, 12 Nov 2014 21:19:07 -0800 context.status: wipe deleted/unknown/ignored fields when reversed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 12 Nov 2014 21:19:07 -0800] rev 23301
context.status: wipe deleted/unknown/ignored fields when reversed It makes no sense to request reverse status (i.e. changes from the working copy to its parent) and then look at the deleted, unknown or ignored fields. If you do, you would get the result from the forward status (changes from parent to the working copy). Instead of giving a nonsensical answer to a nonsensical question, it seems a little saner to return empty lists. It might be best if we could prevent the caller accessing these lists, but it's doubtful it's worth the trouble.
Wed, 12 Nov 2014 23:50:21 -0800 patch.trydiff: add support for noprefix
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:50:21 -0800] rev 23300
patch.trydiff: add support for noprefix
Wed, 12 Nov 2014 23:29:14 -0800 mdiff.unidiff: add support for noprefix
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:29:14 -0800] rev 23299
mdiff.unidiff: add support for noprefix
Thu, 13 Nov 2014 00:13:48 -0800 diff: add a --noprefix option
Siddharth Agarwal <sid0@fb.com> [Thu, 13 Nov 2014 00:13:48 -0800] rev 23298
diff: add a --noprefix option See previous patch descriptions for the motivation. The tests reflect the current state of the world -- as we add support we'll see changes in the test output.
Thu, 13 Nov 2014 00:08:44 -0800 patch.diffopts: add support for noprefix
Siddharth Agarwal <sid0@fb.com> [Thu, 13 Nov 2014 00:08:44 -0800] rev 23297
patch.diffopts: add support for noprefix In an upcoming patch we'll enable support as an option to 'hg diff' as well. The tests reflect the current state of the world -- as we add support we'll see changes in the test output.
Wed, 12 Nov 2014 23:47:25 -0800 patch.diffopts: allow a setting to be forced in plain mode
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:47:25 -0800] rev 23296
patch.diffopts: allow a setting to be forced in plain mode Upcoming patches will add an option that will almost certainly break diff output parsers when enabled. Add support for forcing an option to something in plain mode, as a fallback. Options passed in via the CLI are not affected, though -- it is assumed that any script passing the option in explicitly knows what it is doing.
Wed, 12 Nov 2014 23:44:17 -0800 patch.diffopts: break get function into if statements
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:44:17 -0800] rev 23295
patch.diffopts: break get function into if statements We're going to add another condition here, and with the current structure that becomes just too confusing.
Wed, 12 Nov 2014 23:25:32 -0800 mdiff.diffopts: add a new noprefix option
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:25:32 -0800] rev 23294
mdiff.diffopts: add a new noprefix option By popular demand, we introduce an option to disable the 'a/' and 'b/' prefixes in diff output. This makes copying and pasting filenames from diff output easier. This option will be implemented and documented in upcoming patches. To ensure that existing scripts that parse output don't break, we will ensure that this prefix is disabled in plain mode. A straight 'hg export | hg import' without HGPLAIN=1 will still be broken though, but there's little that can be done about that.
Wed, 12 Nov 2014 23:19:44 -0800 mdiff.diffopts: add doc comment for nobinary
Siddharth Agarwal <sid0@fb.com> [Wed, 12 Nov 2014 23:19:44 -0800] rev 23293
mdiff.diffopts: add doc comment for nobinary
Sat, 08 Nov 2014 17:08:09 +0000 changelog: register changelog.i.a as a temporary file
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 08 Nov 2014 17:08:09 +0000] rev 23292
changelog: register changelog.i.a as a temporary file The file is registered to make sure the transaction is cleaned up in all cases.
Wed, 05 Nov 2014 09:27:08 +0000 transaction: allow registering a temporary transaction file
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 05 Nov 2014 09:27:08 +0000] rev 23291
transaction: allow registering a temporary transaction file During the transaction, files may be created to store or expose data involved in the transaction (eg: changelog index data are written in a 'changelog.i.a' for hooks). But we do not have an official way to record such file creation and make sure they are cleaned up. The lack of clean-up is currently okay because there is a single file involved and a single producer/consumer. However, as we want to expose more data (bookmarks, phases, obsmarker) we need something more solid. The 'backupentries' mechanism could handle that. Temporary files can be encoded as a backup of nothing '('', <temporarypath>)'. We "need" to attach it to the same mechanism as we use to be able to use temporary transaction files outside of .'store/' and 'backupentries' is expected to gain such feature. This changeset makes it clear that we should rename 'backupentries' to something more generic.
(0) -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip