Steven Grimm <koreth@midwinter.com> writes:

quoted text
> 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)

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html