At 8:52 AM -0400 10/2/07, Andy Levy wrote:
>No, I think Ryan heard you perfectly. It's not a "religious
>non-solution" - it's the state of the software right now. Subversion
>doesn't support resource forks and other Mac-specific things at this
>time.
Note that I don't need a Mac-specific solution -- those bits have
been known for years in the Mac developer community.
I'm trying to determine if svn has the necessary hooks to allow me to
implement the platform-specific bits and carefully posed the question
as the general case of encoded binary files.
Of course, the first 2 respondents immediately immediately latched
onto "resource fork" and pounced. :-)
I was considering not using the word at all in order to prevent that
reaction, but wanted to make sure that anyone with the same problem
searching the archive would find the thread.
That's the religious part I'm trying to get past to see if there's a
solution already sitting here, before going off on a development
project that might not be needed.
This attitude is hindering svn's acceptance in the Mac programming
community as it makes it impossible (or at least extremely difficult)
to convert existing repositories.
This is unfortunate as being able to refactor old code while
retaining history is one of svn's primary benefits.
I also noticed that none of the respondents knew the difference
between a resource fork and an AppleDouble header file, yet went on
at great length about how resource forks were evil, etc. and the OP's
problem wasn't worth solving.
The documentation for AppleSingle/AppleDouble is here:
<http://users.phg-online.de/tk/netatalk/doc/Apple/v1/>
The ._ file the Mac OS X creates on non-HFS volumes is an AppleDouble
header file, not a resource fork, although it may (optionally)
contain one.
I tried to provide links to that information in my original post so
that it is possible to have a reasoned discussion of the issues
involved and wether there is a solution without modification to svn.
> > Based your response to my question (and similar questions by Mac OS
>> developers in the past), I can assume your advice to unix users to be
>> "The only solution at present is the one you've already found: don't
>> use unix permissions or symlinks." ;-)
>
>Subversion does store and version symlinks.
Sorry if I misunderstand -- from the header to asvn:
# Description:
# Archive SVN (asvn) will allow the recording of file types not
# normally handled by svn. Currently this includes devices,
# symlinks and file ownership/permissions.
>They get slightly garbled when checked out on Windows (actually
>changed to text files and aren't usable on that OS). So the advice is
>"if you have to share your project with Windows users, you have to
>either not use, or be very careful about how you use, symlinks."
OK, so you hate all non-unix platforms equally. ;-)
So it looks like there's a need for a solution for Windows here as
well -- provide client-side post processing to convert symlinks to
Windows shortcuts.
(Sorry, I don't use Windows, but that doesn't mean I'm not concerned
with a good general cross-platform solution)
> > It seems that the same solution can be applied here by encoding unix
>> permissions in a well-known property giving symlinks a MIME type and
>> fixing them on checkout on unix systems.
>>
>> I'm interested in solving a problem here. It looks like svn is
>> maddeningly close to being useful.
>>
>> It sounds like you're saying that I should be working on the
>> developers list to provide a robust client-side hook system, although
>> I would be interested in finding an easier short-term solution.
>
>Well, yes. It's open source. If SVN isn't scratching all your itches
>and you feel you can contribute to the improvement of the software, by
>all means, roll up your sleeves and dig in.
I'm in the process of determining if that is necessary or if there's
an easier solution lying around in plain sight.
If it is the case, I'm trying to determine if the effort is worth the
time or if the effort will be rejected for religious/political reason
as seems to be the case whenever someone mumbles the phrase "resource
fork" in an svn forum.
If I need to do the work, I'd be interested in knowing if there are
other problems that would be solved by a general client-side
mechanism to fix up files based on their MIME type and/or other svn
properties.
-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 15:55:33 2007