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

Re: Unnecessary crippling of libsvn_fs_base. (Please stop it.)

From: Karl Fogel <kfogel_at_google.com>
Date: 2006-07-18 20:13:14 CEST

"C. Michael Pilato" <cmpilato@collab.net> writes:
>> I can understand the argument that "libsvn_fs is supposed to provide a
>> generic filesystem-style versioned storage layer, and libsvn_repos is
>> supposed to provide repository functionality on top of that". But
>> until now, libsvn_fs had no non-Subversion uses, and it would have
>> made little sense to put functionality into libsvn_fs that Subversion
>> itself would never take advantage of, meanwhile increasing the risk of
>> buggy data getting into someone's repository.
> In this case, the effort wasn't about adding functionality to libsvn_fs that
> wasn't previously there. The effort made was in removing functionality it
> already had. But sure, there's an argument that says, "What if folks used
> libsvn_fs directly in such a way that their later use of that API via
> 'Subversion' caused them problems?" The answer to that is (or should be)
> obvious. If our modules aren't allowed to have all the functionality they
> can have even when that functionality extends beyond the capabilities of
> other modules, then I honestly question the utility of having that code be
> modularized.

The "functionality" I was referring to is the ability to store
arbitrary path names. So "put functionality into libsvn_fs that
Subversion itself would never take advantage of" would mean keeping
the ability to have arbitrary paths -- which we didn't do, hence we
"didn't put" or "didn't keep" that functionality.

Sorry if that wasn't clear.

There are purely architectural reasons to modularize, but yeah, it's
true that the boundary between libsvn_fs and libsvn_repos has always
been one of the blurriest in Subversion.

>> Just don't underestimate the risk/difficulty of moving them to
>> libsvn_repos. There are a lot of calls to check, including all the
>> ones we add in the future. IMHO it's fairly likely that we'll mess up
>> eventually, and someone will end up with bogus paths in a Subversion
>> repository.
> No problems here; I've no underestimations in progress. :-)

I'm not vetoing moving the path-validation checks to somewhere else
(e.g., libsvn_repos), but I'm not volunteering, and Cassandra-like I
call out to warn anyone who tries it that it's Harder Than It Looks:

"It's Harder Than It Looks" :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 18 20:14:17 2006

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.