[PATCH 12 of 27 clfilter V2] clfilter: unfilter some part of the push?logic

Matt Harbison matt_harbison at yahoo.com
Tue Oct 9 21:53:10 CDT 2012


Pierre-Yves David wrote:
> On Tue, Oct 09, 2012 at 04:10:13AM +0000, Matt Harbison wrote:
>> 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?
>
> There is somethign specific in push. We want to know all common changeset
> (including common changeset filtered locally). We need a wide definition of
> common to take advantage of all revision while syncing bookmarks and phases.

OK.  I was thinking unfiltered for push but filtered for 'summary 
--remote' could lead to summary stating '0 outgoing' but push being able 
to do something.


>> 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'.
>
> Using repo.filtered("unserver") should fit your need. But…
>
>> (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.
>
> Are are you not check the return of fco ?. `outgoing.missing` should not
> contains unpushed changeset.

I guess I'm confused then.  'summary --remote' does the following:

         o = outgoing.missing
         if o:
             t.append(_('%d outgoing') % len(o))

to count the number of unpushed csets- unless you mean the lists in 
outgoing objects contain 'str' of the unpushed nodes (not ctxs).

I'm not sure what to check about the return of fco- its 'missing' list 
is just passed back to the parts of largefiles that care about what 
needs to be pushed.  test-largefiles.t runs cleanly when using 
fco().missing, but fails in 3 places if I return a bad list instead (and 
3 more in some additional tests I have).

If this isn't correct, what is the proper method to figure out what 
needs to be pushed?  The comment on fco indicates it should be used, but 
it doesn't specify how.

Thanks for the help.

--Matt


More information about the Mercurial-devel mailing list