[PATCH 12 of 27 clfilter V2] clfilter: unfilter some part of the push logic
Matt Harbison
matt_harbison at yahoo.com
Mon Oct 8 23:10:13 CDT 2012
Pierre-Yves David <pierre-yves.david <at> ens-lyon.org> writes:
>
> # HG changeset patch
> # User Pierre-Yves David <pierre-yves.david <at> ens-lyon.org>
> # Date 1349710867 -7200
> # Node ID 4d3b4de3810fba4ea8e259dfdb96ce5aab816247
> # Parent 40956eab8349b41f1c1b3d143250ad572d976b14
> clfilter: unfilter some part of the push logic
>
> Computation of related to common changeset during push needs to be done on the
> wider set as possible. So an unfiltered version of the repo is kept as end for
> discovery and various revset call. The discovery code itself enforce the
> filtering of unserved outgoing changeset.
Just to help my understanding of how this works- is unfiltered necessary any
time 'commoninc' from fci is passed to fco, or is there something specific to
push that makes this necessary? I ask because it looks like 'summary --remote'
uses a similar method to figure out what is outgoing- does it need unfiltered
too?
I also need to figure out if this affects largefiles, which currently uses fci
to figure out which csets need to be examined for largefiles when pushing, for
'outgoing --large' and 'sum --large'. (I just changed it to fco[1]). It
currently suffers from uploading largefiles in secret csets using either
method, which I'm working on fixing.
> diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
> --- a/mercurial/localrepo.py
> +++ b/mercurial/localrepo.py
> @@ -1879,25 +1879,26 @@
> if not unbundle:
> lock = remote.lock()
> try:
> + unfi = self.unfiltered()
> # discovery
> fci = discovery.findcommonincoming
> - commoninc = fci(self, remote, force=force)
> + commoninc = fci(unfi, remote, force=force)
> common, inc, remoteheads = commoninc
> fco = discovery.findcommonoutgoing
> - outgoing = fco(self, remote, onlyheads=revs,
> + outgoing = fco(unfi, remote, onlyheads=revs,
> commoninc=commoninc, force=force)
>
--Matt
[1] http://www.selenic.com/pipermail/mercurial-devel/2012-October/045062.html
More information about the Mercurial-devel
mailing list