RE: Proposal: generic svn:encoding mechanism

I think that "resource forks" on the Macintosh are something similar to
extended attributes on a linux or NTFS system, except that they are
required for proper operation of executables and enhance the operation of
some data files. I've since seen "resource collections" pop up in Windows
executables as well as on my palm pilot since they first came out on the
mac, but the mac is the only platform I know of where the resources are
placed outside of the normal filestream.

BinHex is a very popular mac utility that is required when downloading any
kind of file off the internet. After it is downloaded, binhex splits the
downloaded file and places the resource fork in the appropriate location.

-----Original Message-----
From: David Anderson [mailto:david.anderson@calixo.net]
Sent: Wednesday, August 03, 2005 12:04 PM
To: Timothy B K. Kientzle
Cc: users@subversion.tigris.org
Subject: Re: Proposal: generic svn:encoding mechanism

Timothy B K. Kientzle wrote:
> This would invoke a "binhex4" encoder prior to commit, "binhex4"
> decoder on checkout, allowing MacOS folks to store files with resource
> forks.

As I have never used MacOS or heard of these elusive "resource forks",
could you elaborate? Besides, the way you're saying is that it should be
encoded on the versionned filesystem, and decoded when checked out? How
does this square with deltification? If you store stuff in a binary form
in the versionned fs, you lose all possibility of saving space. What's
the point? Don't you mean encoding on the fly as it is checked out, to
have the encoded file presented to the user? Yes, reading through the
rest of the mail, looks like you meant that.

> Application #2: svn:encoding=gzip
>
> This would invoke a "gzip" encoder prior to commit, "gzip" decoder
> on checkout. Result is a gzip-compressed file in the repository,
> expanded file on disk.

Again, I fail to see a real gain in doing this. You mean here expanding
the file to have the benefits of deltification, but compress it on
checkout automatically? Why? In fact, why are you storing compressed
files in your repository? Why not just store the uncompressed file and
be done with it?

> This mechanism would also provide a hook for other types of extended
> attribute systems on other platforms in the future.

To be perfectly honest and, well, blunt, this sounds a lot like trying
to find justifications for adding some form of resource fork support in
svn with no other practical use. But I'm open to proof of the contrary
:-).

> There are a few questions to resolve with this: Does the mime-type
> apply to the file on disk or the file in the repo? How do you deal with
> unsupported encodings? These seem pretty mundane issues to me, with a
> variety of reasonable resolutions.

The mime-type issue would probably require some work, because both mime
types would be useful in this case. As for unsupported encodings, the
answer depends on another question you seem to have answered, but forgot
to tell us about: Where is the conversion performed? Client-side or
server-side?

If on the server side, you have the problem of needing to install many
other programs on the server, that might not even be available (binhex
manipulation tools might not be available on the platform the server is
operating off). If on the client side, you run into the same problems
that you do with client-side scripting: how can you assume that all
clients will have the required tools to perform encoding conversion? If
they don't, what do you do? Each user therefore has a working copy that
is different for the same repository version, depending on available
third-party programs?

Another question you elude: you speak of 'gzip encoder' and 'gzip
decoder'. How do you identify these programs on the system? Do you
assume that gzip means /usr/bin/gzip ? Do you provide extra properties
for specifying the actual binaries? How do you solve diverging path
issues (one client stores it in /usr/bin/gzip, another in
/usr/local/bin/gzip, another calls it /opt/bin/gzip, another has
/home/foo/bin/gnu-zip which is gzip compatible, etc.) ?

Sorry for being blunt. I'm interested in the implications of what you're
saying, but I'm trying to understand and help you flesh out your
proposal a little, whilst at the same time throwing in my general
feeling of "why is this actually useful?" :-).

- Dave.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org