summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2013-12-05 16:00:39 +0000
committerLars Wirzenius <liw@liw.fi>2013-12-05 16:00:39 +0000
commit15eb3b40ecfd0bd4117695d8fa991df60f1cee24 (patch)
tree5523282e8f4cfa6099e211747fe8819a3d7c81c5
parentce6a9d5fedecd84a6c5bc1ff940d41bbd798b87f (diff)
downloadobnam-15eb3b40ecfd0bd4117695d8fa991df60f1cee24.tar.gz
Add scenario for multiple generations
-rw-r--r--yarns/0040-generations.yarn60
-rw-r--r--yarns/9000-implements.yarn8
2 files changed, 68 insertions, 0 deletions
diff --git a/yarns/0040-generations.yarn b/yarns/0040-generations.yarn
new file mode 100644
index 00000000..39eb8c9e
--- /dev/null
+++ b/yarns/0040-generations.yarn
@@ -0,0 +1,60 @@
+Multiple backup generations
+===========================
+
+This chapter contains tests for Obnam's handling of multiple
+generations: making incremental backups, forgetting generations, and
+so on. We assume that backing up any individual directory tree works
+fine, regardless of whether it is for the initial generation or an
+incremental one. In the previous chapter for basic backups, we've
+already dealt with those. This chapter focuses on generation handling
+only.
+
+Incremental backup generations (`obnam backup`)
+------------------------------
+
+First of all, most importantly, we must be able to make more than one
+backup generation, and restore them. The live data in each generation
+is different, but there are unchanged parts as well. For simplicity,
+we'll assume that if we can do two generations, we can do any number.
+It's possible that the 12765th generation might break, but that's
+unlikely, and it's even less likely we'll guess it. (If it turns out
+to actually happen, we'll add a regression test when we find the
+problem.)
+
+ SCENARIO backup two generations
+ GIVEN 1MB of live data
+ AND a manifest of live data in G1
+ WHEN user backs up live data
+ GIVEN 2MB of live data
+ AND a manifest of live data in G2
+ WHEN user backs up live data
+ AND user restores generation 1 to R1
+ AND user restores generation 2 to R2
+ THEN live data, restored to R1, matches manifest G1
+ AND live data, restored to R2, matches manifest G2
+
+Listing generations (`obnam generations`, `obnam genids`)
+-------------------
+
+FIXME.
+
+Listing contents of a generation (`obnam ls`)
+--------------------------------
+
+FIXME.
+
+Comparing generations (`obnam diff`)
+------------------------------------
+
+FIXME.
+
+Forgetting a specific generation (`obnam forget`)
+--------------------------------
+
+FIXME.
+
+Forgetting generations according to a schedule (`obnam forget --keep`)
+-------------------------------------------------------------
+
+FIXME.
+
diff --git a/yarns/9000-implements.yarn b/yarns/9000-implements.yarn
index d43b8a28..bd264c92 100644
--- a/yarns/9000-implements.yarn
+++ b/yarns/9000-implements.yarn
@@ -109,6 +109,14 @@ We need a way to restore data from a test backup repository.
IMPLEMENTS WHEN user restores their latest generation into (\S+)
run_obnam restore -r "$REPO" --to "$DATADIR/$MATCH_1"
+Restore a specific generation. The generation number is an ordinal in
+the list of generations, not the "generation id" Obnam assigns, as
+that is unpredictable.
+
+ IMPLEMENTS WHEN user restores generation (\d+) to (\S+)
+ id=$(run_obnam -r "$REPO" genids | awk -v "n=$MATCH_1" 'NR == n')
+ run_obnam restore -r "$REPO" --to "$DATADIR/$MATCH_2" --generation "$id"
+
Checks on files
---------------