On Oct 2, 2007, at 2:00 PM, Steve Sisak wrote:
> The basic proposal, based on the discussion, is to allow:
>
> 1) Client-side encoding/decoding of files based on the MIME type
> and/or other properties of files in the repository
>
> 2) Standard svn properties for platform-specific properties.
>
> A general solution would be to have a client-side architecture
> where handlers could be defined per MIME type to wrap files before
> check-in and unwrap into local for on checkout.
All of us in the Mac community (and that definitely includes me!)
wish this problem would get solved. But the CVS solution to this
problem, which I believe you've been using with MacCVS Pro, (called
cvswrappers) is widely held to have been unsuccessful. There are
basically two reasons for this: first, the client-side, non-standard
processing complicates installation and fault analysis, and second,
so long as it remains specific to what is (sadly, we must all admit)
a minority platform, it will fall out of use, or possibly into other,
evil uses (as the CVS implementation did), and leave those of us
dependent upon it marooned in "the last working version." And of
course, Resource Forks are passé, even in the Mac world ;-)
For these reasons, I think most of us would rather see extensions
that could handle "opaque tree structures" (wink wink - bundles!).
This seems more likely to have actual use in non-Mac places as well;
it's already cropped up in areas like pocket database storage and GPG.
In a cvs2svn context, then, how would you feel if cvs2svn were to
learn to transform resource forks into bundles? I believe there are
standard mappings and tools between file+fork and bundle+resource-
file, aren't there? So even if your app isn't happy about bundles
rather than resource forks (which I've heard some aren't), you'd have
a path.
As for standard properties ... easiest thing in the world: set 'em,
and don't change your mind about what they're called! So long as all
the providers working on a particular feature can agree on the prop
name (and values), no one else will mind in the least.
> This identical in concept to svn storing file names in UTF-8 and
> converting to local conventions on checkout.
Yeah, identical as in "golly, wouldn't it be nice if that one were
fixed, too???"
-==-
Jack "who foolishly added over 400 UTF-8 file names to his company's
product" Repenning
jackrepenning@tigris.org
Project Owner
SCPlugin
http://scplugin.tigris.org
"Subversion for the rest of OS X"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 02:16:45 2007