Re: Using git as a general backup mechanism

From: Junio C Hamano <junkio@cox.net>
Date: Dec 15, 2006, 00:33 UTC
Message-ID: <7vwt4uxaj4.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <4581DF3E.3070806@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

Show 15 quoted lines

> Junio C Hamano wrote:
>>  (2) End of week comes.  Create an empty branch 'weekly' if you
>>      do not already have one.  Make a full tree snapshot, and
>>      create a parentless commit for the week if the 'weekly'
>>      branch did not exist, or make it a child of the 'weekly'
>>      commit from the last week.  Discard 'lastweek' branch if
>>      you have one, and rename 'daily' branch to 'lastweek'.
>
> That sounds like it'd work, but doesn't it imply that the history of a
> given file in the backups is not continuous? That is, an old copy of a
> file on the "weekly" branch doesn't have any kind of ancestor
> relationship with the same file on the "daily" branch? While that's
> obviously no different than the current git-less situation where
> there's no notion of ancestry at all, it'd be neat if this backup
> scheme could actually track long-term changes to individual files.

You can keep them connected by rewriting history of bounded number of commits. When you start a new week, you would make the Monday commit a child of the tip of weekly branch that represents the latest weekly shapshot. Then on Friday, the history would show the 5 commits during the week and behind that would be a sequence of commits with one-per-week granularity. When you rotate the week's daily log out and the commit for Monday is based on the weekly history you are going to toss out, you may need to rebase that week's daily log branch.

Let's say your policy is to keep daily log for at least one week and enough number of end-of-week weekly logs. Let's say it is week #2 right now.

                        Aooo... (week #2 daily)
                       /|
                ooooooB |  (week #1 daily)
               /        |
     o--------o---------C (end-of-week weekly log)

The first commit in this week's daily log (A) would have two parents: last commit from daily log of week #1 (B), and the latest commit on the end-of-week weekly log (C). Most likely, B and C would have exactly the same tree. That way, you would have at least 7 days of daily log; at the end of this week you would have close to 14 days but "keeping at least one week" is satisfied.

When starting the 3rd week, you will discard 1st week's log; you would need to rewrite 7 days worth of commits from week #2, because the first commit of week #2 should now only have one parent (C), and you would forget the commit on the last day of week #1 as its parent (B). Which cascades through 7 commits you made during week #2. You are not changing any trees, so this should be quite efficient.

Then the first daily commit of 3rd week would have two parents, the commit at the end of week #2 daily branch (D), and a new commit (E) at the tip of the end-of-week log. Again, D and E would have the identical trees.

                                o...... (week #3 daily)
                               /|
                        Aooo..D |  (week #2 daily)
                        |       |
 (week #1 daily - gone) |       |
                        |       |
     o--------o---------C-------E (end-of-week weekly log)