John Peacock wrote:
> 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.
>
It doesn't have to know the specifics of the binary format, that's for
external utilities to manage. It would be nice though if subversion
could be configured to automatically call these external utilities
before commits and after update/checkouts, so the user doesn't have to
manually do multiple steps.
> 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.
>
An external wrapper suffers from the same issues, and is more of a pain
to setup and use. At least with client side hooks, once the config file
and filter programs are set up, using subversion remains exactly the
same. With an external wrapper, the repository administrator would have
to build a wrapper program, support it for each platform, distribute it
to clients, and users would have to learn to use the wrapper instead of
svn directly.
> 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.
>
I don't see why there is a problem putting the onus of configuring the
client side hooks on the client user. I'd rather make them manually
configure their client than automatically import things from the server
which could manipulate their system in ways they do not want, and likely
be platform specific to boot. Besides, subversion works perfectly fine
without the client side scripts. If you want to use them to gain some
additional benefits, then you can put up with the additional
configuration required.
>
> 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."
>
Again, it doesn't, it only needs to allow the user to configure it to
invoke external filters. Let the filters worry about the details.
>> 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.
>
I can not imagine how one could modify the compression algorithm to be
'rsyncable'. I wonder has anyone tested this to see if it actually does
any good?
> 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
>
Is it really that hard to take a configuration directive to execute an
external filter program?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 8 22:19:28 2005