[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Incomplete SVN dump files

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 16 Sep 2015 22:50:09 +0000

Eric Johnson wrote on Wed, Sep 16, 2015 at 11:03:08 -0700:
> On Wed, Sep 16, 2015 at 2:33 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
> > After an error you can't trust that the final portion is ok.
> >
>
> Sure, but why not encode that in the dump itself! The absence of an
> "end-commit" trailer could be a signal to every tool that uses the dump
> that the commit is not complete, and the transaction could be discarded!

Off the top of my head, the dump side could include the number of
changed paths in the revision (i.e., apr_hash_count(svn_fs_paths_changed2()))
in the start-of-revision block. That would be easy enough to implement
without breaking either streamyness or backwards compatibility.
Individual files are already checksummed. Ditto for reprop changes
(they have Prop-content-length:, which suffices). Therefore any early
truncation would be detected. svndumpfilter will need to either
recompute or strip the new header.
Received on 2015-09-17 00:50:23 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.