Mac OS does the same thing on FAT32 that it does with UFS: create
a ._ file containing a binary copy of the data in the resource fork.
Unfortunately, removing resource forks from this project is not an
option, at least not in the short term. The app we are developing is
a decade old, and has 200+ dialogs and countless strings stored in
resource forks. We hope to move it to using .nib's but this would
take a lot of time and effort and bring no change as far as our users
are concerned.
The current version control consist of making a copy of the source
directory when we ship a new version or are about to add a major new
feature. This is far from ideal, but until we can check out the
source on 10.4, it'll have to do.
-Richard
On 20/05/2006, at 1:25 PM, Nico Kadel-Garcia wrote:
> Richard Stephens wrote:
>> thanks, thats helpful. We do have machines running 10.3, but one of
>> the machines that will be accessing the repository is an intel imac,
>> and 10.4 isn't available on intel.
>>
>> Is there a way to either make the OS not move the resource forks, or
>> to make subversion check out the ._ files first/
>>
>> -Richard
>>
>> On 19/05/2006, at 8:31 PM, Ryan Schmidt wrote:
>
>>> On May 19, 2006, at 08:00, Richard Stephens wrote:
>>> On Mac OS X 10.4, Apple "helpfully" modified the built-in commands
>>> which move and copy and remove files, so that they also move and
>>> copy and remove the separate resource fork files on filesystems
>>> like UFS where they exist. So as soon as Subversion tells the OS to
>>> move foo from within the .svn directory to outside of it, the OS
>>> "helpfully" moves the ._foo file along with it. Subversion does not
>>> know that this has occurred, and thinks ._foo is still in the .svn
>>> directory waiting to be moved. So Subversion tells the OS to move
>>> the file ._foo, and—heavens to Betsy—it's not there and an error
>>> occurs.
>>>
>>> Possible conclusions one can draw from this:
>>>
>>> * Mac OS X 10.4 is broken.
>>> * Resource forks cannot be used with Subversion.
>
> Or the more correct conclusion:
>
> * Resource forks are a bad idea, corrupting software and
> filesystems willie-nillie.
>
>>> The only solution I can suggest is to place your resource fork-
>>> containing files on a disk image, and check the disk image into
>>> Subversion. You'll no doubt be able to see why that's less than
>>> ideal. And the other solution is to use Mac OS X 10.3.x or
>>> earlier and
>>> never upgrade.
>
> It's not the OS. It's the file-system, which admittedly may be
> dependent on the OS. What does MacOS these days do with FAT32 and
> other, simpler file systems?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 20 05:41:18 2006