You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@red-bean.com> on 2004/11/19 17:18:46 UTC
Locking: regarding fsfs
Okay, after a couple of weeks, I think we've hammered out a reasonable
implementation of locks in BDB. Huge thanks to striker and cmpilato
(and brane, for preventing us from going down a bad road!)
The locking branch compiles now, and you can play with the BDB
repository locks using the three new 'svnadmin' commands. I'm gonna
start writing some new fs-tests (the C tests) to check that locks are
being properly enforced during write operations, both on-the-fly and at
final commit time. The fsfs implementation of locks will be able to
use the same tests too.
Speaking of fsfs, can I entice anyone to start working on it? ghudson?
jpieper? Or somebody else dying to learn the internals of fsfs?
A lot of the groundwork has already been laid out for you:
* multiple passes/cleanups the 5 new API signatures and their
promises
* new shareable APIs to pass a username & lock-tokens into an fs_t
* new shareable APIs to verify that locks are usable by the committer
* a BDB reference implementation to imitate, if need be. :-)
* coming soon, a test suite.
A chance to write new code is pretty rare -- this is your chance to
have some fun.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: regarding fsfs
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> If you look through fs-tests.c, there's only 3 calls to svn_fs__* in
> 42 tests. (And they're svn_fs__id_t's). Everything else is public fs
> API calls. I think we're just a tiny skip away from making fs-tests.c
> generic for any fs back-end. I like the idea of adding an
> "--backend=fsfs" switch or something.
"--fs-type", like the cmdline tests. This is more or less what I had in
mind, yes. Sorry if I wasn't clear enough. The unit test infrastructure
might need some work to get this through, and run_fs_tests.py should
call fs-tests twice, once for BDB and once for FSFS.
> (And meanwhile, bdb- or fsfs- specific tests can live in separate
> collections, like skel-test.c)
Right. I still think we should split them into the correct directories,
though; libsvn_fs, libsvn_fs_base and libsvn_fs_fs. There's
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: regarding fsfs
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Nov 20, 2004, at 1:39 PM, Branko Čibej wrote:
>
> What about skel-tests, then? They're a BDB implementation detail.
>
Hm, yah, so maybe that README is just out-of-date. But notice they're
in a separate file.
>
>
> We only have tests for libsvn_fs_base, which is pretty BDB-centric. We
> really should refactor those tests.
>
If you look through fs-tests.c, there's only 3 calls to svn_fs__* in 42
tests. (And they're svn_fs__id_t's). Everything else is public fs API
calls. I think we're just a tiny skip away from making fs-tests.c
generic for any fs back-end. I like the idea of adding an
"--backend=fsfs" switch or something.
(And meanwhile, bdb- or fsfs- specific tests can live in separate
collections, like skel-test.c)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: regarding fsfs
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
>
> On Nov 20, 2004, at 12:04 PM, Branko Čibej wrote:
>
>> Ben Collins-Sussman wrote:
>>
>>> Okay, after a couple of weeks, I think we've hammered out a
>>> reasonable implementation of locks in BDB. Huge thanks to striker
>>> and cmpilato (and brane, for preventing us from going down a bad road!)
>>>
>>> The locking branch compiles now, and you can play with the BDB
>>> repository locks using the three new 'svnadmin' commands. I'm gonna
>>> start writing some new fs-tests (the C tests) to check that locks
>>> are being properly enforced during write operations, both on-the-fly
>>> and at final commit time. The fsfs implementation of locks will be
>>> able to use the same tests too.
>>
>>
>> We should really break down fs-tests into general, BDB-specific and
>> FSFS-specific tests, then make it understand the --fs-type option.
>> Right now I believe we still test BDB more rigorously than FSFS in
>> the unit tests.
>>
>
> That would directly contradict the instructions in
> subversion/tests/README. That doc seems to be talking about testing
> public APIs, and *not* writing tests for implementation details.
What about skel-tests, then? They're a BDB implementation detail.
> Is that doc just out-of-date? Do we have any existing fs-tests that
> are BDB-specific or FSFS-specific? I don't think we do... I think
> it's all public APIs. Has FSFS never been run through fs-tests.c? It
> should work.
I don't see how. Last I saw, it didn't parse the --fs-type option, so it
always uses the default -- which is BDB.
We only have tests for libsvn_fs_base, which is pretty BDB-centric. We
really should refactor those tests.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: regarding fsfs
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On Nov 20, 2004, at 12:04 PM, Branko Čibej wrote:
> Ben Collins-Sussman wrote:
>
>> Okay, after a couple of weeks, I think we've hammered out a
>> reasonable implementation of locks in BDB. Huge thanks to striker
>> and cmpilato (and brane, for preventing us from going down a bad
>> road!)
>>
>> The locking branch compiles now, and you can play with the BDB
>> repository locks using the three new 'svnadmin' commands. I'm gonna
>> start writing some new fs-tests (the C tests) to check that locks are
>> being properly enforced during write operations, both on-the-fly and
>> at final commit time. The fsfs implementation of locks will be able
>> to use the same tests too.
>
> We should really break down fs-tests into general, BDB-specific and
> FSFS-specific tests, then make it understand the --fs-type option.
> Right now I believe we still test BDB more rigorously than FSFS in the
> unit tests.
>
That would directly contradict the instructions in
subversion/tests/README. That doc seems to be talking about testing
public APIs, and *not* writing tests for implementation details. Is
that doc just out-of-date? Do we have any existing fs-tests that are
BDB-specific or FSFS-specific? I don't think we do... I think it's all
public APIs. Has FSFS never been run through fs-tests.c? It should
work.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Locking: regarding fsfs
Posted by Branko Čibej <br...@xbc.nu>.
Ben Collins-Sussman wrote:
> Okay, after a couple of weeks, I think we've hammered out a reasonable
> implementation of locks in BDB. Huge thanks to striker and cmpilato
> (and brane, for preventing us from going down a bad road!)
>
> The locking branch compiles now, and you can play with the BDB
> repository locks using the three new 'svnadmin' commands. I'm gonna
> start writing some new fs-tests (the C tests) to check that locks are
> being properly enforced during write operations, both on-the-fly and
> at final commit time. The fsfs implementation of locks will be able
> to use the same tests too.
We should really break down fs-tests into general, BDB-specific and
FSFS-specific tests, then make it understand the --fs-type option. Right
now I believe we still test BDB more rigorously than FSFS in the unit tests.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org