Change Details

As other loaders do, if any files is bigger than 100Mib, this content is not ingested in the swh archive. Implementation wise (storage related), this ends up referenced in the `content_missing` table (with associated hashes). For the deposit, those deposits should end up rejected. This will make sure that if a deposit is injected in the archive, its associated software source code will be cookable (that and T1714 :)

As other loaders do, if any file is bigger than 100Mib, its associated content is not ingested in the swh archive. Implementation wise (storage related), this ends up referenced in the `content_missing` table (with associated hashes). For the deposit use case, deposits matching that criteria should end up rejected (with an explicit 'reason'). Implementation wise, the functional checks could walk the deposit's associated archive and ensure the files respect this limit. If not reject as usual the deposit. Goal: Make sure that a deposit's (injected in the archive) associated software source code is cookable (that and T1714 :)

As other loaders do, if any files is bigger than 100Mib, thisits associated content is not ingested in the swh archive. Implementation wise (storage related), this ends up referenced in the `content_missing` table (with associated hashes). For the deposit use case, those depositsdeposits matching that criteria should end up rejected (with an explicit 'reason'). This will make sure that if a deposit is injected in the archiveImplementation wise, itsthe functional checks could walk the deposit's associated archive and ensure the files respect this limit. If not reject as usual the deposit. Goal: Make sure that a deposit's (injected in the archive) associated software source code will beis cookable (that and T1714 :)