Bug 3245 - largefiles: largefiles size is not enforced on the server
Summary: largefiles: largefiles size is not enforced on the server
Status: RESOLVED ARCHIVED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: largefiles (show other bugs)
Version: unspecified
Hardware: All All
: normal feature
Assignee: Bugzilla
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-03 08:02 UTC by Marcin Wisnicki
Modified: 2015-02-07 01:00 UTC (History)
7 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marcin Wisnicki 2012-02-03 08:02 UTC
Currently largefile size and patterns are only used by client. There should
be a way to store and enforce these settings on the server (ie. reject push
with ordinary files that are too big).
Alternatively, a way to automatically propagate this configuration to clones.

$ hg version
Mercurial Distributed SCM (version 2.0.2)
Comment 1 Bugzilla 2012-05-12 09:27 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:27 EDT  ---

This bug was previously known as _bug_ 3244 at http://mercurial.selenic.com/bts/issue3244

Bug Status was UNCONFIRMED but everconfirmed was true
   Setting status to CONFIRMED

Comment 2 Na'Tosha Bard 2012-12-09 10:46 UTC
I am wondering about the best implementation here.  It seems like it would be most "correct" to, somehow, check the file size before doing the upload at all.  Currently, when pushing, we have:

1) a batched set of statlfile commands is sent to the server (asking the server if it has any or all of the largefiles that are about to be uploaded)
2) a single response containing the server status of all queried largefiles is sent back
3) the individual files are uploaded as separate requests

I guess the appropriate behavior would be to have an extra step between 2 and 3, where the client asks the server about the validity of the sizes of each file about to be uploaded?
Comment 3 Bugzilla 2015-02-07 01:00 UTC
Bug was inactive for 789 days, archiving