History transfer: qualify incremental archives beyond bounded whole-project caps
Maintainers usually reply within 9 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading the verified history transfer and archive export and verification paths, then trace how bundles, packets, invocations, and the newest canonical pointer are represented. The payload names no files or tests, so locate those entry points and their existing coverage first. Done means versioned shards preserve complete ranges and cross-shard references, bind to the exact project and digest, support bounded verification and idempotent recovery, and never silently drop history or reinterpret existing versions.
Written by the indexing model from the issue text.
Description
The new verified history transfer intentionally caps a whole-project snapshot (64 MiB by default, configurable to 512 MiB; 2,000 records per category). A long-lived or busy adopter will eventually exceed a bounded whole-store archive. Increasing the cap indefinitely would remove the memory/verification bound.
Follow-up acceptance: versioned incremental/sharded archive manifests with explicit complete ranges, retained cross-shard bundle/packet/invocation references and exact project/digest binding; bounded listing/verification; idempotent resume and recovery; newest canonical pointer preserved; no silent dropped generations, pruning or reinterpretation of existing archive/bundle versions.
Current 0.5.0 behavior is a clear cap error and no partial export. This is a scalability debt, not permission to omit older private history or call a partial backup complete.
- Dominant language
- Python
- Stars
- 4
- Forks
- 1
- Avg merge
- 5d 12h
- Merged PRs (30d)
- 3
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from drevendev/Devostasis
-
Difficulty 1/5 Under an hour Newbie friendliness 65/100
drevendev/Devostasis#25 ·
Maintainers usually reply within 9 days
-
good first issue hacktoberfest help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 56/100
drevendev/Devostasis#78 ·
Maintainers usually reply within 9 days
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
drevendev/Devostasis#77 ·
Maintainers usually reply within 9 days
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
drevendev/Devostasis#76 ·
Maintainers usually reply within 9 days
-
Offline Git collection: isolate inherited repository context and credential environmentPossibly taken @abogun-product claimed this 11 days ago. Open
Difficulty 3/5 1-2 days Newbie friendliness 25/100
drevendev/Devostasis#74 ·
Maintainers usually reply within 9 days
All issues in drevendev/Devostasis
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
SublimeText/AdvancedNewFile#211 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 73/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
Imbad0202/academic-research-skills#987 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Pull-through from gcr.io returns 500 when pulling using podman/buildahPossibly taken A pull request linked to this issue is open or already merged. OpenIssue Triage-Needed
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
pulp/pulp_container#2581 ·
Maintainers usually reply within 1 day