From 646f4409fe52a5a6601b26ea73bea470caff04ff Mon Sep 17 00:00:00 2001 From: Gabriel Filion Date: Mon, 17 Nov 2014 12:24:50 -0500 Subject: [PATCH] Correct claim about number of packs per backup The current sentence implies that there is only one pack file per backup run, which is not necessarily correct. Because of the "constants" max_pack_size and max_pack_objects that are used as limits to pack sizes, we may end up with more than one pack per backup if there is a lot of data that needs to be stored. Signed-off-by: Gabriel Filion [rlb@defaultvalue.org: adjust commit summary] Reviewed-by: Rob Browning --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f66dd4e..fab4904 100644 --- a/README.md +++ b/README.md @@ -353,8 +353,8 @@ python. Basically, 'bup split' reads the data on stdin (or from files specified on the command line), breaks it into chunks using a rolling checksum (similar to -rsync), and saves those chunks into a new git packfile. There is one git -packfile per backup. +rsync), and saves those chunks into a new git packfile. There is at least one +git packfile per backup. When deciding whether to write a particular chunk into the new packfile, bup first checks all the other packfiles that exist to see if they already have that -- 2.39.2