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

Re: Ruby binding test of fs failing on windows

From: Kouhei Sutou <kou_at_cozmixng.org>
Date: 2007-01-16 15:57:37 CET

Hi,

In <ae6cb1100701151651y12503867g60305cb14db929a5@mail.gmail.com>
  "Ruby binding test of fs failing on windows" on Mon, 15 Jan 2007 16:51:47 -0800,
  "Joe Swatosh" <joe.swatosh@gmail.com> wrote:

> in http://thread.gmane.org/gmane.comp.version-control.subversion.devel/84157/focus=84157
> Brane, Vlad and I conclude that this (taken from test_fs.rb) is
> probably not a good test:

I'm sorry. I missed the thread.

> Interface changes:
> - Add a close method to Svn::Fs (that would release the new pool
> member added to Svn::Fs which would close the filesystem).
> - Add a block form to Svn::Fs.open, Svn::Fs.new, and Svn::Fs.create
> (with the obvious implementations).
>
> Implementation changes:
> Here I'm kind of fuzzy. I think that we'd have to add a pool member
> to Svn::Fs (initialized as a "subpool" of the class variable pool?)
> and pass it into Svn::Ext::Fs.create or Svn::Ext::Fs.open, which would
> mean modifying their signatures and implementations to use it instead
> of the global.

It seems that a block form solution is good. But I can't
implement this because I don't want to expose pool related
API to Ruby side. I just removed
Svn::Fs::FileSystem.delete. Could you give me a time to
think about the implementation?

> There are similar issues with a test in test_repos.rb.

Is the test SvnReposTest#test_create, isn't it? I'll fix it
soon. And I'll fix SvnFsTest#test_create too.

> Many questions:
> Should we just delete the test since it is a poor usage example?

I want to keep providing a Svn::Fs::FileSystem.create usage
example.

> Should we modify Svn::Fs as above? Or some other way?

Yes.

> Am I on the right track here at all?

I think so.

> I suppose the block forms could come latter, if you even think this is
> an direction worth pursuing.

I agree with you.

Thanks,

--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 16 15:57:57 2007

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

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