Mon, 19 Oct 2015 15:42:50 +0200 shelve: properly process bundle2 bundle
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 19 Oct 2015 15:42:50 +0200] rev 26799
shelve: properly process bundle2 bundle
Tue, 20 Oct 2015 03:07:23 +0200 histedit: properly apply bundle2 backups
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 03:07:23 +0200] rev 26798
histedit: properly apply bundle2 backups If the histedit fails, we restore a backup. We make sure this backup bundle can be in bundle2 format as general delta will require.
Tue, 20 Oct 2015 16:01:33 +0200 strip: pass source and url to bundle2 processing
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 16:01:33 +0200] rev 26797
strip: pass source and url to bundle2 processing Restoring from a 'bundle2' was missing this data.
Tue, 20 Oct 2015 15:56:22 +0200 unbundle: use 'url' argument with applybundle
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:56:22 +0200] rev 26796
unbundle: use 'url' argument with applybundle This will let the hook get access to the 'url' value.
Tue, 20 Oct 2015 15:55:04 +0200 applybundle: take url as argument
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:55:04 +0200] rev 26795
applybundle: take url as argument We allow specifying the url to carry it to hooks. This gets us closer to 'bundle1.apply(...)' and will allow us to remove regressions in multiple place where we forget to pass the url to hooks.
Tue, 20 Oct 2015 15:53:07 +0200 unbundle: use 'source' argument with applybundle
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:53:07 +0200] rev 26794
unbundle: use 'source' argument with applybundle This will let the hook get access to the 'source' value.
Tue, 20 Oct 2015 15:52:42 +0200 applybundle: take source as argument
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:52:42 +0200] rev 26793
applybundle: take source as argument We allow specifying the source to carry it to hooks. This gets us closer to 'bundle1.apply(...)' and will allow us to remove regressions in multiple places where we forget to pass the source to hooks.
Tue, 20 Oct 2015 15:48:24 +0200 applybundle: set 'bundle2=1' env for all transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:48:24 +0200] rev 26792
applybundle: set 'bundle2=1' env for all transaction This should be set for all bundle2 application, we enforce that at a low level. This is for courtesy with hooks.
Tue, 20 Oct 2015 15:47:20 +0200 unbundle: use 'bundle2.applybundle'
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:47:20 +0200] rev 26791
unbundle: use 'bundle2.applybundle' This is one such place.
Tue, 20 Oct 2015 15:45:39 +0200 bundle2: introduce an "applybundle" function
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 20 Oct 2015 15:45:39 +0200] rev 26790
bundle2: introduce an "applybundle" function There is a case where the intent is clear and the transaction is not optional. We want to be able to alter that transaction in a wide and easy way. We cannot get a unified '.apply(repo)' method for bundle1 and bundle2 yet because the api are still a bit too far apart. But this is a good step forward to get the rc out.
Thu, 15 Oct 2015 01:31:04 -0700 commands.resolve: conclude merge driver if no unresolved files are left
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:31:04 -0700] rev 26789
commands.resolve: conclude merge driver if no unresolved files are left This can happen when either 'hg resolve --all' is called or a driver-resolved file is explicitly requested. This is done as part of 'hg resolve --all' so that users still have a chance to test their changes before committing them. The exact semantics here are still to be decided. This does not impact any non-experimental features. Thanks to Pierre-Yves David for some advice about this behavior in particular, and merge drivers in general.
Thu, 15 Oct 2015 01:27:06 -0700 commands.resolve: call driverpreprocess if we haven't run it yet
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:27:06 -0700] rev 26788
commands.resolve: call driverpreprocess if we haven't run it yet We need to be careful about allowing --mark and --unmark to keep working -- we don't want the user to be stuck in a weird state. The exact behavior here is still to be decided, though.
Thu, 15 Oct 2015 01:22:01 -0700 merge.applyupdates: call driverconclude after performing merge actions
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:22:01 -0700] rev 26787
merge.applyupdates: call driverconclude after performing merge actions This will be a chance for the merge driver to finish resolving or generating any driver-resolved files. As before, having a separate error state from 'unresolved' is too big a refactoring for now, so we hack around it by setting unresolved to a positive value when necessary.
Thu, 15 Oct 2015 01:19:10 -0700 merge.applyupdates: call driverpreprocess before starting merge actions
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:19:10 -0700] rev 26786
merge.applyupdates: call driverpreprocess before starting merge actions We also need to update our internal state to whatever state driverpreprocess leaves it in. Adding an error state separate from the unresolved count is too big a refactoring for now, so we hack around it by setting it to a positive value to indicate an error state.
Thu, 15 Oct 2015 01:17:29 -0700 merge: add stubs for preprocess and conclude steps of merge driver
Siddharth Agarwal <sid0@fb.com> [Thu, 15 Oct 2015 01:17:29 -0700] rev 26785
merge: add stubs for preprocess and conclude steps of merge driver The exact semantics for what should happen (particularly with respect to error handling) are still a bit hard to pin down, so I think it's better to experiment with it as an extension for now. For now this stub will act as a convenient point for extensions to hook on.
(0) -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip