At 5:16 PM -0700 10/2/07, Jack Repenning wrote:
>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.
Yes, maintaining a project-specific settings file
has been a perpetual pain and I agree it's a
suboptimal solution.
Now given that I have an existing CVS repository
that's been maintained with MacCVS Pro, I'd like
to get it into svn so that I can clean up the
tree and refactor and modernize the code --
preferably without losing my history.
>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 ;-)
Unfortunately, I have code that still has to
build (and, believe it or not, I still get
requests for Mac OS 9 code).
Also, since I write QuickTime components for a
living (my primary business is video input device
drivers), there are places where resources are
_required_ by even current system software.
Passé or not, I still need to support Mac OS
resource forks, types and creators (those are on
their way back) and other Mac OS file metadata.
That said, there are well known encodings for
these (that aren't going to change) and since svn
supports versioned attributes, including MIME
type, and since all of the standard encodings
have well known MIME types, simply tagging
encoded files with their proper MIME type and
building support for those types into the Mac svn
client (if the file is encoded as AppleSingle,
MacBinary or MacBinHex and we're on MacOS, decode
to a native Mac file) would be a complete
solution for me.
I also believe Matt's solution has merit (if a
file in has a file:appledouble property and we're
on MacOS, extract the additional metadata to
create a native Mac file).
This would solve the immediate problem, not
interfere with other platforms, and not open the
cvswrapper can of worms (which could be dealt
with separately).
So, to repeat, my immediate need is to get my
existing repository into svn so I can clean it up
and modernize it, but still be able to extract
the source tree for an old driver because a large
corporation needs it tweaked to work with a
different model of a video cameras because the
old model is no longer available.
>For these reasons, I think most of us would
>rather see extensions that could handle "opaque
>tree structures" (wink wink - bundles!).
I have no problem with that either, however (I think) it's a different problem.
(This isn't an "either or" situation)
>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.
Right.
But if you cast the problem as "support for
general MIME type decoding", that has general
usefulness. Supporting Mac OS files attributes is
just a test case.
>In a cvs2svn context, then, how would you feel
>if cvs2svn were to learn to transform resource
>forks into bundles?
That wouldn't help because it would leave me with a tree that I can't build.
>I believe there are standard mappings and tools
>between file+fork and bundle+resource-file,
>aren't there?
No. There are data fork only resource files that you can put in a bundle.
I'd have to change code to do things the "new"
way so, therefore, I couldn't even build my
current, shipping, tree.
>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.
I write QuickTime components, which use resources in required places. period.
And Mac OS files have more extended attributes
than just resources. Look at what is in an
AppleSingle/Double file.
>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.
That's fine with me.
The MIME types for Mac OS file encodings have
been set in stone for at least a decade (maybe 2).
Matt has proposed file:appledouble for the
property which contains the AppleDouble header
file (associate with a given data file) -- the
format of the contents has been defined since
A/UX. Unless there are major objections from
someone, it's fine with me.
My requirement for converting from CVS to svn is
that I be able to convert my repository and still
be able to extract and build a client delivery
from 2 years ago.
Supporting the standard Mac OS MIME encodings in
the Mac OS svn client, will meet that requirement
completely (wether or not there is a full
cvswrapper equivalent, which I wouldn't object to
as an escape mechanism).
This will get me onto svn and let me modernize my
code while retaining the ability to go back in
history and recover old versions as needed.
I've also got no problem with (and would
contribute to) opaque tree structures, better
support for packages, Open Office OOo files, etc.
>>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???"
I got it working OK (including the .µ extension
on CodeWarrior projects), but I was confused
until I figured out I had to set my locale to
UTF-8 english.
(I had to put the cvs repository on a UFS disk
image and set the encoding to mac-roman, but once
I got both set, the files came across.)
My point here is, that in this case, svn uses a
general format internally (Unicode) and converts
to a local format on checkout (although it ought
to remember the original encoding on a
per-platform basis).
Anyway thanks for the note -- I'll be glad to
help out, but I think we need to handle both the
legacy and forward-looking cases.
Feel free to suggest alternatives.
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 3 03:55:56 2007