On Oct 1, 2007, at 22:07, Steve Sisak wrote:
> 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.
The aforementioned admonishment is for Subversion's server-side hook
scripts. There are no client-side hook scripts in Subversion. 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. 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Oct 2 06:20:49 2007