I'm in the process of determining if I can convert a good-size CVS
repository containing
7 years of Mac OS code that has been maintained with MacCVS Pro
<http://sourceforge.net/projects/maccvspro/> in order to maintain Mac
OS file attributes (type, creator, finder info, resource forks, etc.)
that would be lost by using cvs directly.
Here are the cvs2svn statistics on the repository to give an idea of the size:
cvs2svn Statistics:
------------------
Total CVS Files: 5803
Total CVS Revisions: 24686
Total CVS Branches: 30046
Total CVS Tags: 559038
Total Unique Tags: 383
Total Unique Branches: 29
CVS Repos Size in KB: 350255
Total SVN Commits: 10513
First Revision Date: Mon Jun 12 15:09:38 2000
Last Revision Date: Thu Aug 16 11:24:12 2007
Searches of this list for suggestions on how to handle Mac OS
resource forks and file attributes has yielded little help beyond the
usual unhelpful religious arguments (don't use resource forks because
our tools don't handle them).
There does appear to be an obvious solution if svn could be convinced
to allow a local hook to encode/pre-process files on checkin and
decode.post-process them on output.
There are 4 standard encodings for Mac OS files for platforms/file
systems that do not understand Mac OS file attributes, each with
assigned MIME types:
MacBinary application/macbinary
<http://en.wikipedia.org/wiki/MacBinary>
BinHex application/mac-binhex4 <http://en.wikipedia.org/wiki/Binhex>
AppleSingle application/applefile
<http://en.wikipedia.org/wiki/AppleSingle>
AppleDouble multipart/appledouble
<http://en.wikipedia.org/wiki/AppleDouble>
Based on a local settings file, MacCVS Pro allows files to be encoded
in any of the single file encodings (all but AppleDouble) in the
repository and automatically decoded on checkout to a normal file
with its resource fork and file attributes intact.
(In reading the list archive, it appears that there is a common
misunderstanding that the ._ file produced by Mac OS X on file
systems that do not support extended attributes it the resource fork.
It is not. It is an AppleDouble headerfile, which is essentially an
AppleSingle file without the data fork)
Given that svn supports MIME types and I have a repository that
already contains encoded files, I ought to be able to set the MIME
type of these files properly (i.e. application/macbinary) and have a
Hook Script that decodes the file (based on the MIME type) into a
normal Mac OS File and on check-in, encode a local file based on its
repository MIME type before storing in the repository.
This is similar to what asvn is attempting to solve for unix file
permissions and symlinks as well.
It is also identical in concept to svn storing file names in UTF-8
and converting to local conventions on checkout.
Unfortunately there is the following admonishment on p. 93 of svn-book:
>Warning
>Do not attempt to modify the transaction using hook scripts. A
>common example of this
>would be to automatically set properties such as svn:eol-style or
>svn:mime-type
>during the commit. While this might seem like a good idea, it causes
>problems. The main
>problem is that the client does not know about the change made by
>the hook script, and
>there is no way to inform the clienprising and unexpected behavior.
So, I'm looking for guidance is there any way to implement the
desired behavior cleanly without patching svn (which I'm willing to
do).
I've tried to couch this in platform independent terms as it seems
completely rational to encode platform-specific file attributes as
svn properties -- there just needs to be a way to do it in a way that
does not confuse the client.
I'm avoiding the multi-stream issue with AppleDouble (._ files) as my
existing data happens to be in single-file format, but am open to
suggestions.
Thanks,
-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 05:07:41 2007