Feature: Delete policies and ordering (--delete-before, --delete-after, --delete-excluded, --max-delete) #179
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Corresponding rsync flags/behavior:
--delete— already implemented: delete files on receiver not in source--delete-before— delete before starting transfer--delete-after— delete after completing transfer--delete-excluded— also delete excluded files on the receiver--max-delete=N— don't delete more than N filesCurrent FastSync behavior:
FastSync implements only
--delete, and deletions happen after the manifest is received (effectively--delete-after). There is no control over ordering, no--delete-excluded, and no limit on the number of deletions.Proposed changes:
--delete-before,--delete-after(default),--delete-excluded,--max-delete=NDeletePolicy delete_policy,bool delete_excluded,int max_delete--delete-before: build manifest during scan, send it early, wait for server to finish deletions before sending file data--delete-after: current behavior--delete-excluded: include excluded source paths in the manifest so the receiver removes them--max-delete=N: abort if deletion count exceeds NSTATUS_DELETE_MANIFESTsent before data when--delete-beforeis usedPriority: medium
Rationale: Ordering matters for disk-space management (
--delete-beforefrees space before receiving) and safety (--max-deleteprevents catastrophic deletes).Acceptance criteria:
--delete-beforeremoves extra files before any new data is written--delete-excludedremoves files on the receiver that match source--excludepatterns--max-delete=10aborts when more than 10 files would be deleted--delete-after