Daniel Shahaf wrote on Thu, Dec 15, 2011 at 20:27:22 +0200:
> C. Michael Pilato wrote on Thu, Dec 15, 2011 at 11:08:25 -0500:
> > On 12/15/2011 10:24 AM, Daniel Shahaf wrote:
> > > That's an interesting approach. But can we do without the log files?
> > > Is there an easy way to, given N, capture all the table rows that belong
> > > to revisions youngest than rN?
> >
> > I suppose that depends on what you mean by "easy". We'd need a whole bunch
> > of custom code on both the read and write side of things.
> >
>
> The question was aimed at understanding the scope/breadth of the new
> code that would be required.
>
Should say: the point here is to have the amount of data copied be
proportional to the time since the last incremental hotcopy. The 'hot
backup' method described in the BDB docs you attached to the issue has
does not have this property during the bootstrap step (of copying the
data files), but does have it[*] during subsequent steps of copying only
the log files.
Daniel
[*] if we ignore the pathological case of many revprop/lock/etc changes
that were done and alter reverted.
> > > (And would we ever need to delete DB rows from the hotcopy? The above
> > > algorithm assumes append-only tables.)
> >
> > No, we cannot maintain an perfect row-by-row copy in append-only mode.
> >
> > At a minimum we have to deal with deltification, which for older BDB formats
> > happens constantly in already-committed revisions, and for newer formats can
> > also occur at the administrator's request. But that's a storage detail, and
> > (I think) doesn't affect the semantic sanity of such a backup.
>
> OK, so the parts of the database that aren't append-only are those used
> by the APIs svn_fs_change_rev_prop(), svn_fs_deltify_revision(), and
> svn_fs_lock().
>
> >
> > More pressing is the matter of revision properties, which of course can
> > change at any time. (How did the FSFS code handle that one, even?)
>
> Stefan says the new hotcopy --incremental code recopies all historical
> revprop files.
Received on 2011-12-15 19:50:53 CET