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.
> > (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:28:14 CET