I really like the idea of being able to configure the subversion client
to filter files through arbitrary programs, which could include
unzipping. I also don't see any security problems if it is done in a
sane way. I propose this:
1) Use a property to inform the client that it should use a given filter
on the file
2) The client configuration file would list acceptable filters, possibly
on a per repository basis, and map them to the local executable that
performs the filtering
3) svn add already does some kind of checking to decide if the file is
binary or text. This could be extended to recognize the mime type of
the file in more detail, and based on settings in the client
configuration file, automatically set the filter property based on the
mime type.
This would prevent the client from executing arbitrary code at the
direction of the server without the user's consent, but allow automatic
filtering. Obviously the client would need to be configured to handle
each filter used in the repository, but eventually commonly used filters
would probably come preconfigred with the subversion install.
In the event that a repository uses filters that do not come out of the
box, then the administrator would need to direct the clients of the
repository how to configure their system to use the filters. If the
client runs into a filter it does not know how to handle, then it could
fail and inform the user of the problem.
John Peacock wrote:
> Hadmut Danisch wrote:
>> Allow to configure arbitrary transformation programs (e.g. just a
>> shell script) on the client side, which recognize files on a pattern
>> base and run them through that filter instead of putting them directly
>> into that archive.
>
> Client side scripting has been discussed in the past; there are a couple
> of obvious problems:
>
> 1) security;
> 2) Subversion is a fully cross-platform tool and some people's computers
> are infested with OS's with incompetent shells and no robust scripting
> capability;
> 3) distribution of repository standard scripts to clients isn't
> available (though at least this is expected to change at some point);
> 4) did I mention security?
>
> There is nothing stopping you from producing a wrapper to the svn binary
> which does whatever massaging you want to the data before calling svn
> itself. If it is really useful in the general case, you can submit it
> to the Subversion project and it could live along side the other
> contrib/client-side tools.
>
> John
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 20:01:51 2005