Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:42:29 -0700] rev 41937
uncommit: move _movedirstate() to scmutil for reuse
The function should be applicable generically when moving from one
commit to another. I'll try to add more callers when I find time.
I'm not convinced it's handling all the cases correctly, but we should
have a generic function for this kind of operation, so I think it
belongs somewhere in core (not in the uncommit extension).
Differential Revision: https://phab.mercurial-scm.org/D6119
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:20:26 -0700] rev 41936
copies: remove dependency on scmutil by directly using match.exact()
I want to add a dependency from scmutil.copies(), so I need to remove
this dependency first.
Differential Revision: https://phab.mercurial-scm.org/D6118
Martin von Zweigbergk <martinvonz@google.com> [Mon, 11 Mar 2019 09:35:36 -0700] rev 41935
uncommit: convert _fixdirstate() into _movedirstate()
_fixdirstate() already also updates to the given commit, so let's
rename it to _movedirstate(). Also update the documentation and drop
the unnecessary "curctx" argument, since that should always be
repo['.'].
Differential Revision: https://phab.mercurial-scm.org/D6117
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:34:12 +0100] rev 41934
updatecaches: also warm the tags caches
Resolving any name requires the tags cache to be warm. We make sure that `hg
debugupdatecache` warm the tag cache entry too.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Mar 2019 02:32:21 +0100] rev 41933
updatecaches: also warm revbranchcache for filtered revisions
We are in the "full" case, so we better warm everything we can.
Sushil khanchi <sushilkhanchi97@gmail.com> [Wed, 13 Feb 2019 15:50:14 +0530] rev 41932
copies: handle a case when both merging csets are not descendant of merge base
This patch fix the behaviour of fullcopytracing algorithm in the case
when both the merging csets are not the descendant of merge base.
Although it seems to be the rare case when both the csets are not
descendant of merge base. But it can be seen in most of cases of
content-divergence in evolve extension, where merge base is the common
predecessor.
Previous patch added a test where this algorithm can fail to continue
because of an assumption that only one of the two csets can be dirty.
This patch fix that error.
For refrence I suggest you to look into the previous discussion held
on a patch sent by Pulkit: https://phab.mercurial-scm.org/D3896
Differential Revision: https://phab.mercurial-scm.org/D5963
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 16:09:43 +0530] rev 41931
copies: add test that makes both the merging csets dirty and fails
This patch is a part of series which is about the case when both the merging
csets are not descendant of merge base. The existing code assumes if c1 is
dirty there shouldn't be any partial copies from c2 i.e both2['incomplete']
and same for c2, if c2 is dirty both1['incomplete'] should be empty,
but this is not the right assumption.
Now as we know we can have both c1 and c2 dirty at the same time, it
is possible that c1 is dirty and both2['incomplete'] has some value.
Or if c2 is dirty and both1['incomplete'] has some value.
Added test shows that because of this assumption it could fail.
Differential Revision: https://phab.mercurial-scm.org/D5962
Sushil khanchi <sushilkhanchi97@gmail.com> [Thu, 14 Feb 2019 17:11:35 +0530] rev 41930
copies: add test that makes both the merging csets dirty and run w/o error
This series of patches is to cover a case in fullcopytracing algorithms
where both the merging csets are not descendant of merge base.
In this algorithm we call a merging cset "dirty" if that cset is not the
descendant of merge base. That said, added test in this patch cover case
when both the merging csets are "dirty".
Actually this case of "both dirty" was encountered by Pulkit when he was
working on content-divergence where it is possible that both the csets
are not descendant of merging base.
For reference you can look into: https://phab.mercurial-scm.org/D3896
As this test run fine without any error and correctly traced the copies, I
added this test to make sure that it doesn't break even after I will modify
some code in next patches to fix an error. Next patch adds the tests where
this algorithm throws an error for the same case of "both dirty".
Differential Revision: https://phab.mercurial-scm.org/D5961
Matt Harbison <matt_harbison@yahoo.com> [Sun, 10 Mar 2019 16:51:21 -0400] rev 41929
tests: stabilize test-bundle.t on Windows
Similar to
92055d539e49.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 19:01:56 +0100] rev 41928
discovery-helper: use reflink copy if available
A reflink copy will copy the files "as usual" but keep using the same data block
underneath. This is only supported by "copy on write" file system like btrfs or
zfs.
This will achieve similar performance that the existing hardlink clone that
Mercurial performs with the same initial space saving. However, it will behave
better on revlogs start being touch by strip. Instead of duplicating all data in
the touched revlogs, only the block actually affected by the strip will be
duplicated. This save a lot of space when building many variants of large
repositories.
The --reflink=always flag make sure the `cp` call fails if reflink copies are
not supported. Falling back to local clone.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 18:52:22 +0100] rev 41927
discovery-helper: bail out if destination already exists
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 10 Mar 2019 18:50:38 +0100] rev 41926
discovery-helper: move repository creation in a function
This makes it easier to update this duplicated code.
(we do a small output fix as we go)