Re: Pre/Post-processing files on check-in/out

At 11:18 PM -0500 10/1/07, Ryan Schmidt wrote:
>The aforementioned admonishment is for Subversion's server-side hook scripts.

OK, that (client vs. server side) wasn't completely clear in the hook
documentation.

>There are no client-side hook scripts in Subversion.

So that's the deficiency.

>Your resource forks, file type and creator, and Finder info and such
>will be lost if you import them into Subversion in its current
>incarnation.

They are _already_ imported into subversion without losing the
metadata (via being coverted from an already-encoded CVS repository).

I'm working on setting up the environment to get them out and decoded
automatically, as I have been doing for 7 years with CVS.

This does not require any changes to svn on the server side for, as
far as the server is concerned, these are just binary files with MIME
type application/macbinary.

The specific case is that I'm just trying to get the client side to
automatically decode application/macbinary, etc. files to normal
files when checked out onto an a operating system or file system
(HFS, HFS+, NTFS) that understands unencoded Mac files.

This is exactly analogous to svn storing file names in UTF-8 and
decoding them to whatever encoding is used by the local file system.

The general case is being able to store platform (OS, filesystem)
specific data of files (and directories) preserved in svn properties
and applied when checked out in environments where it is meaningful.

>There's not a great solution to your problem at this time. The only
>solution at present is the one you've already found: don't use
>resource forks, etc.

I don't think you're hearing me here -- as I attempted to make
crystal clear in the background info, this is the kind of religious
non-solution I'm not interested in. Since I have an existing
repository, it maps to "don't use subversion".

(I may be sticking with with CVS for a bit longer, since it does
handle the situation, albeit awkwardly)

What I hear you saying (confirmed by additional additional) is that
subversion lacks client-side hooks and relies on a combination of
hacks and wrapper scripts (see
<http://subversion.tigris.org/tools_contrib.html#asvn>) to work
around the lack of a mechanism for preserving platform-specific
file/directory metadata.

I'm not calling asvn a hack here -- just a specific non-Mac example
of addressing the general deficiency, where subversion loses unix
permisiions and can't store symlinks.

Based your response to my question (and similar questions by Mac OS
developers in the past), I can assume your advice to unix users to be
"The only solution at present is the one you've already found: don't
use unix permissions or symlinks." ;-)

It seems that the same solution can be applied here by encoding unix
permissions in a well-known property giving symlinks a MIME type and
fixing them on checkout on unix systems.

I'm interested in solving a problem here. It looks like svn is
maddeningly close to being useful.

Off list, I was also pointed to a solution for AppleDouble:

  <http://www.ambrosiasw.com/~fprefect/subversion-appledouble.html>

which encodes the Mac-specific information in a file:appledouble
property in the repository.

This, and asvn, may be a starting point.

It sounds like you're saying that I should be working on the
developers list to provide a robust client-side hook system, although
I would be interested in finding an easier short-term solution.

In the shorter term, I might be able to use an asvn-style wrapper and
a server-side hook script to prevent check-in of files that aren't
properly encoded.

-Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 14:44:12 2007