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.
