On Feb 10, 2008 10:13 AM, Joe Swatosh <joe.swatosh_at_gmail.com> wrote:
> Hi Dave,
>
> On Feb 8, 2008 3:47 PM, <glasser_at_tigris.org> wrote:
> > Author: glasser
> > Date: Fri Feb 8 15:47:56 2008
> > New Revision: 29250
> >
> > Log:
> > Yet another node-origins-cache-for-FSFS implementation! This one
> > hopefully is the best of all worlds: create a new style of node
> > IDs which encode the origin revision directly into the node ID, but
> > continue to have an on-disk cache for old node IDs, but save disk
> > space by using cmpilato's patch to store up to 36 IDs in each file.
> >
> > Note that because new node IDs don't need to be cached, we can remove
> > the "gather new node IDs during commit and cache them in bulk" code,
> > which in fact even removes the need for any bulk-cache-writing code at
> > all.
> >
> > Also, properly handle node-IDs that have never been committed.
> >
>
> >
>
> This commit causes failures in the Ruby bindings tests. Here is an example:
>
> path = File.join(@tmp_path, "fs")
> fs_type = Svn::Fs::TYPE_FSFS
> config = {Svn::Fs::CONFIG_FS_TYPE => fs_type}
>
> Svn::Fs::FileSystem.create( path, config )
>
> assert_raises(Svn::Error::Cancelled) do
> Svn::Fs::FileSystem.recover( path ){raise Svn::Error::Cancelled}
> end
>
> assert_nothing_raised do
> Svn::Fs::FileSystem.recover( path ){}
> end
>
> Perhaps svn_fs_recover() no longer supports cancel?
More or less. FSFS recovery consists of two things: finding the
maximum revision (relatively quick) and finding the next node and copy
IDs (relatively slow). We only used cancellation in the latter, and
as of this revision, FSFS version 3 doesn't actually have next
node/copy IDs any more, so we don't run that bit of recovery.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-11 18:34:06 CET