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.
I wonder if rebasing can get me what I want. Something like:
(1) Make a new branch from the latest daily. Commit a full tree
snapshot to the new branch. (Each branch has exactly one commit.)
(2) To expire a daily backup, rebase the second-oldest daily branch,
which will initially be a child of the oldest daily branch, under
the latest weekly branch instead. Delete the oldest daily branch.
I believe the right commands here would be:
git-rebase -s recursive -s ours --onto latest-weekly \
oldest-daily second-oldest-daily
git-branch -D oldest-daily
(Not sure about the double "-s", but I want it to detect renames
where possible and never flag any conflicts.)
(3) At the end of the week, instead of expiring the oldest daily
branch, rename it to indicate that it's now a weekly snapshot.
(That will implicitly do the first part of step 2, since the
next daily branch in line will already be a descendant of the
newly renamed branch.)
Repeat step 2, rebasing against the latest monthly branch,
to expire the oldest weekly.
(4) To expire an old monthly, rebase the second-oldest monthly branch
under the initial empty revision, then delete the oldest monthly.
This is basically step 2 again, but rebasing under a fixed starting
point.
(5) Run git-prune to expire the objects in the deleted branches, then
git-repack -a -d to delta-compress everything.
That's a bit convoluted, admittedly, and probably a perversion of
everything pure about the branch system, but would it work? The big
thing I'm not sure about here is whether, after doing my rebase and
delete in step 2, the objects from the oldest daily will actually be
removed by git-prune. They should be unreachable at that point, I think.
-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html