[PATCH RFC] largefiles: abort push when ordinary file fit largefile pattern (issue3245)

Pierre-Yves David pierre-yves.david at ens-lyon.org
Thu Jul 14 20:42:49 EDT 2016



On 07/06/2016 01:47 PM, liscju wrote:
> # HG changeset patch
> # User liscju <piotr.listkiewicz at gmail.com>
> # Date 1467747171 -7200
> #      Tue Jul 05 21:32:51 2016 +0200
> # Node ID 5d1ce681c75b02482cf8a96c47609efa864b4d16
> # Parent  6a98f9408a504be455d4382801610daceac429e6
> largefiles: abort push when ordinary file fit largefile pattern (issue3245)
> 
> So far setting minsize and patterns for largefiles worked only
> locally changing which files were added/committed as largefiles.
> It did not prevent pushing ordinary files that exceeded minsize
> or matched pattern for largefiles on server.
> 
> To solve this there are two possible solutions:
> 1) Check ordinary files before pushing, if they match pattern
> for largefiles on server - abort push
> 2) Check ordinary files when there are unbundled on server,
> abort when there are files that match pattern for largefiles
> 
> This commit is an implementation of #1 idea to discuss and needs
> some changes before being merged.
> 
> This solution at first downloads minsize and patterns from server,
> check if any of files exceeds minsize or match pattern and if it
> does aborts push.
> 
> This solution works only when server/client has version of hg that
> support this checking. Idea #2 would work for any client as far as
> server has support for this, but the drawback of this idea is that
> checks are done after sending files to server.

I've not reviewed the actual code yet, but it seems like we should sure
a mix of (1) and (2). Having the client checking will save bandwidth,
while (2) ensure we behave properly in all cases even if the client do
not implement (1).

Another question that raise from this patch is "is there a way to
disable it?" I can imagine project with older changeset exceeding the
limit that still need to get pushed from time to time.

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list