Jim Blandy wrote:
> We draw the line around doing a good job handling as many reasonable
> use cases as we can see how.
Ah, therein lies the rub. I don't think this (autoexpanding zip
archives or special handling for OO files) is a reasonable use case. I
don't think Subversion has any business encoding knowledge about some
other application's binary file format. If the other app wants to use
Subversion more efficiently, let them interface with us.
I am slightly less negative about adding client-side hooks to perform
transformations on files prior to committing. I don't think the OP (and
others) have thought through all of the ramifications of this sort of
change. I think it is much more reasonable to do this as a wrapper to
Subversion, for _now_, because of both the security issues and the lack
of standard scripting tools on all of the platforms where Subversion runs.
It would by much easier to sell "run this when you hit a file with this
type and then take the updated file for storage" if, and only if, there
were server managed configurations. Client side hooks are brittle
enough without that, but trying to distribute user config files
out-of-band (not to mention potentially unversioned) is a nightmare.
This one feature (server-managed config) alone would solve an enormous
number of issues. At that point, a client side hook feature becomes
palatable and more importantly manageable.
> What's wrong here is that your real answer is, "I can't see how to do
> that well, without causing other problems" --- a perfectly fine answer
> --- but what you've written is, "This tool isn't supposed to do that."
> Those are different arguments.
I'm arguing that "Subversion wasn't *intended* to do that, it is tuned
for text; and furthermore, in order to do that in Subversion would
require an unnecessary amount of some other project's internal structure
to intrude on Subversion."
> If we could see a good solution (I
> think making OO use "rsyncable" compression is a great solution), then
> we *would* want to do it.
If making OO files more friendly to Subversion is possible, I'm all for
it. I don't have any problem with that. The Subversion project doesn't
have to basically do anything there. I don't think that there is too
much hope for that (as pointed out by someone else, zip archives are a
collection of individually zipped files, which is AFAIK, not true of
gzip, even though the actual compression algorithms are related).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 8 21:44:43 2005