I agree to much of what Malcolm says. Some further comments below:
Malcolm Rowe writes:
> On Tue, Jan 16, 2007 at 11:36:58PM -0800, David Anderson wrote:
> > [good stuff]
>
> * I don't think we should try providing two libsvn_wc implementations.
Completely agree. That maintainance burden is too high!
> Either libsvn_wc_sqlite can implement all the public svn_wc functions
> or it can't. If the former is true, we should just replace the
> implementation. If the latter, I don't see how we can make this usable
> without declaring Subversion 2.0 (in which case, see the former).
>
I don't think a reasonable new API should try to support the old one. IMO, it
is just too low-level for that. To me, this is a 2.0 thing.
> * You mention that we aren't seeing any movement on optional textbases
> due to the state of libsvn_wc. From what I understand, it's not just
> the state of the implementation, but the assumptions by the _users_
> of libsvn_wc as to how the implementation works. I understood that
> the next step in fixing those problems should be to remove some of
> those assumptions from the current users. That's still true even if
> you replace libsvn_wc.
>
Yep, libsvn_client also has assumptions of text bases being available.
Back when I was thinking of solving the optional textbase issue, I was
loosly thinking of adding callbacks so that libsvn_wc could indirectly
call into libsvn_ra. This would be compatible as long as you didn't use
the new feature. That would probably be a bit messy, though...
> * I like the design of using a single (SQLite) database in the root of
> the working copy. I agree that we'd need a severability operation for
> those people who need to use it, but that we can make that explicit.
> From what I recall, that was the same conclusion some of us reached
> at the Summit in October (though I can't remember who was involved in
> the conversation).
>
I think we should consider allowing all WC metadata to be in a central
store somewhere. Say you have your working files on NFS, then you could
have your metadata on local disk for performance. That's a thing we can
flesh out later, though. I agree that central storage (per WC root or
overall) is necessary.
> * I think the 'svn edit' mode of operation shows some promise, but I
> think we should put off implementation until we have the current mode
> working well. We should take it into account in the design though.
If we get rid of entries reading and WC locking/unlocking for every dir,
then the crawling shouldn't cost much more for svn status than for calling
make for an incremental build. So, I am not sure we need this feature.
Typical projects who have slow svn status would have slow incremental builds
which they might want to solve anyway. But I'm not closing the door
entirely.
>
>
> I think that the next steps should be to write down the problems we're
> trying to solve (and those we aren't) and come up with a concrete design
> that we can validate against those requirements. I'd also like to know:
>
> - how we're going to solve the assumptions made by users of libsvn_wc
> in our codebase (I don't think we need to worry about assumptions
> made by other users). For example, do we introduce operations to
> encapsulate access to the text-base files.
>
As long as we are in 1.x land, we need to be backwards compatible. That's
a promise we made.
> Finally: I'd love to help. I'm not sure how much time I'll have though.
>
+1, without any actual promises on my side, though;)
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 17 13:54:51 2007