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

Re: Autoexpanding ZIP archives?

From: Hadmut Danisch <hadmut_at_danisch.de>
Date: 2005-12-07 18:49:03 CET

On Wed, Dec 07, 2005 at 12:26:10PM -0500, Greg Hudson wrote:
> Still, Hadmut, just because it's possible to do better here doesn't mean
> it's worthwhile. How would you feel if Subversion corrupted your data
> because it went through an obscure, poorly-tested code path to optimize
> storing it?

Bad, because that would be a poor way to implement it.

I'd propose a different way:

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.

As an example, I could have all files of pattern *.odp (opendocument)
not put in SVN directly, but zip-extracted. Simple task to write a
shell script to transform this. This would allow to store the contents
uncompressed (or compressed by file), while having the regular
opendocument file on the client side.

I could imagine even more examples for such transformers:

- Character Code conversion. E.g. svn server has UTF-8, I have

- I'd love to put my Firefox bookmarks in a repository. Unfortunately,
  it does not just contain the bookmarks, but access dates as well,
  which causes plenty of changes just by using Firefox and the
  bookmarks. I'd have a transformer which just removes that access
  dates and leaves the bookmark information.

- Encryption (which is the opposite of my zip proposal):
  Have the encrypted data on the SVN server, decrypt when downloading,
  encrypt when committing.

- Digital Signatures

- Further scripting, e.g. postprocess configuration files stored in
  SVN, restart a daemon, etc.

That way SVN wouldn't know anything about zip archives or
presentations. It's just my client who is configured to call a
particular program to do any magic transformation.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Dec 7 18:53:10 2005

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.