At 9:32 AM +0200 10/3/07, Michael Haggerty wrote:
>FWIW, a couple of months ago I added an option to cvs2svn to unpack
>AppleSingle files during the conversion, but the current code throws
>away everything but the data fork (because SVN doesn't have a way to
>store the other info!) This was helpful to a user who didn't need the
>other resources. This code is in the trunk version of cvs2svn and is
>accessible when starting cvs2svn via the options file method via the
>ctx.decode_apple_single option.
OK, this is very useful -- to support MacCVS Pro, we'd want to add
support for MacBinary and BinHex as well (possibly only in cvs2svn),
but that's just adding well-known code.
>I know this is not a solution to the problem being discussed; I just
>wanted to let you know that it is out there.
Thanks -- I didn't know it was there and it would very much be part
of a solution once we solve the issue of losslessly encoding MacOS
files in a Subversion repository.
Once we get that working, how would you feel about adding a rule for
handling a MacCVS Pro settings file to cvs2svn?
This would automatically set the file encoding, text/binary, eol
mode, etc. type/creator, etc. based on what would have happened had
the project been checked out by MacCVS Pro.
Then, on check-in if the file has a resource fork (which would only
happen if it were encoded in CVS), we put it into svn as AppleSingle,
otherwise, if the file has a type/creator assigned, we check in the
data fork and add an AppleDouble property to preserve that info.
(For that matter, we could just adopt Matt Slott's patch and just
save everything as AppleDouble in the repository)
-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 14:41:08 2007