Ticket Change Details

Artifact ID: b2ac75ba78e3eb7b6ec72c3093ea379e8af65451
Ticket: 22962fd50076048f30b72a41f992feefb7440cd2
Snapshot sync facility
User & Date: alaric 2016-09-25 17:10:51

  1. Change comment to:

    Building on the core logic in [1d491d7ec2], we could also sync snapshot tags between vaults.

    Again, we name source and destination tags. If the destination tag exists it must be a snapshot tag, and it must point to a predecessor of what the source tag points to, so it can just be advanced after the content has been synchronised.

    If the destination tag does not exist, it can be created.

    The mirroring should be able to be limited to the depth of snapshot chain it traverses (with a number of snapshots, or a date limit, either as an absolute date or "now minus specified interval". If there is no existing destination tag, we create the chain with a dangling pointer if we hit the limit. If there is an existing destination tag, then the current state of it must be an ancestor of the source tag within the limit.

    Unless a special "rebase" option is given - in which case, we don't directly copy snapshot blocks, but copy their contents and update the "previous" pointer to point to what's currently on the destination tag (or none if it didn't exist), just like a git rebase. That makes it easy to, say, once a month sync across the most recent snapshot, to create a vault that has one snapshot per month while the main one has a snapshot per day, etc.

  2. Change login to "alaric"
  3. Change priority to "UNSPECIFIED"
  4. Change severity to "UNSPECIFIED"
  5. Change status to "Open"
  6. Change subsystem to "UNSPECIFIED"
  7. Change title to "Snapshot sync facility"
  8. Change type to "Feature_Request"