On Mar 29, 2004, at 10:51 PM, Greg Hudson wrote:
> Anyway, comments appreciated. I'm also interested in comments about
> how we ought to structure this work so that it doesn't disrupt the
> main thrust of Subversion development.
I don't have any real comments about your specific FS design plans,
other than to say that they seem reasonable to me and I'll try to pitch
in as you go forward and I develop more clue about that part of the
system.
As for how to structure this work so that it doesn't disrupt the main
thrust of Subversion development, I'm thinking that a good first step
would be to modify libsvn_fs such that it makes use of a vtable for all
calls into the underlying filesystem implementation, as has been
discussed on the list before, and then once that's in place in the
trunk create a branch for development of the new FS impl.
Actually, I suppose I don't have any strong feelings about doing the
development of the new impl on a branch, but I think it makes some
sense just because I'd prefer not to have parts of it in any release
until it's up and limping along and we have some confidence that it's
going to work well, and since we don't really know how long the
development is likely to take it seems safer to do that work on a
branch out of the way. I think libsvn_ra_svn succeeded mainly because
when it was presented for public consumption it was largely complete,
so before this shows up in the trunk I'd hope it would be similarly far
along. On the other hand, I think a filesystem impl is a considerably
bigger job than an RA layer, so I think it would be better off to do
the development in the repository in view of others who may be able to
help than in a vacuum as you did with libsvn_ra_svn.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 14:49:30 2004