You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Richard Stephens <ri...@createng.com.au> on 2006/05/20 01:03:17 UTC
checking out mac resource forks, file checkout order
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:
>
>> I'm trying to set up subversion to do source control, and the
>> files we're using have resource forks, which are not checked in by
>> subversion.
>>
>> I found that if I created a read/write UFS disk image, and copied
>> the source to there, it could be checked in and the resource fork
>> would be maintained in the form of a file with the same name but
>> with "._" before it.
>>
>> Only problem is, when i try to check them out, it fails on
>> seemingly random files. It's always the "._" files, and they
>> check out fine on a windows machine.
>>
>> In an attempt to isolate the problem, I pulled out a few small
>> files that cause it to fail from the main source tree, and checked
>> them in. When I checked them out again, it failed. Renaming them
>> by putting a 2 at the end makes it checkout properly but this is
>> not a satisfactory solution.
>>
>> This is what happens on the terminal:
>>
>> imac-intel-2ghz:/Volumes/Untitled 1 Richard$ /usr/local/bin/svn
>> checkout svn://192.168.51.3/gworldstest wd/
>> A wd/._QuickTime Work
>> A wd/QuickTime Work
>> A wd/QuickTime Work/._Gestalt
>> A wd/QuickTime Work/GWorlds
>> A wd/QuickTime Work/Gestalt
>> A wd/QuickTime Work/._GWorlds
>> svn: In directory 'wd/QuickTime Work'
>> svn: Can't copy 'wd/QuickTime Work/.svn/tmp/text-
>> base/._GWorlds.svn-base' to 'wd/QuickTime Work/._GWorlds.tmp': No
>> such file or directory
>> imac-intel-2ghz:/Volumes/Untitled 1 Richard$
>>
>> Gestalt was included because i wanted to use a file which I know
>> did not fail.
>>
>> Any idea? Thanks in advance
>
> 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.
>
> 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.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Stephen Davis <st...@mac.com>.
On May 19, 2006, at 8:42 PM, Richard Stephens wrote:
> 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.
Another option is to convert the resource files to data fork
resources which can be done with the tools inside /Developer/Tools
(Rez, ResMerger). That is certainly simpler than switching off of
Resources entirely. We did that at work years ago when X was first
becoming important. All the tools can deal with data fork resources
so this shouldn't break anything.
hth,
stephen
Re: checking out mac resource forks, file checkout order
Posted by Richard Stephens <ri...@createng.com.au>.
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
Re: Off-topic MacOS resource flaming, was : Re: checking out mac
resource forks, file checkout order
Posted by Evert | Collab <ev...@collab.nl>.
Nico Kadel-Garcia wrote:
>
>
> Take a look at thedata actually on the disk. It's in two files, it's
> in two separate places on the disk. The kernel obscures this. It's not
> an "arbitrary amount data". The kernel has to access the directory
> structure (admittedly) to deal with things like the name of the file,
> the file itself, and in the case of these MacOS file filesystems, the
> resource fork. The resource fork is an extra operation *to the disk*:
> it's stored separately.
>
Lots of files are stored in multiple blocks on a disk..
The difference between windows and (old) mac resources:
* windows stores the resource data at the end of a file
* mac stores it in a separate file
* to get the resource information in windows, you would have to seek to
that point
* in mac, you could open the resource file
In the case of obtaining the data, mac wins, because:
in the inode table (well thats how its called with ext2/3, im sure
hfs/fat/ntfs have different names for that) only the first location is
stored per file.. To find a certain spot in a file you would have to
follow that location and obtain the location for the next block in that
location. To find the resource information you would have to traverse
through all the blocks (a seek operation)
For Mac, you can simply open the known location, also in most cases this
table is cached, so it turns out to be _a lot_ faster..
However, this discussion is pretty pointless.. the reason the old mac
resource forks are obsolete now is for a simple.. its inconvenient.
Speed is not much of an issue.. most normal file operations completely
ignore resources except in the UI.. (finder/explorer)
Take a look at thedata actually on the disk. It's in two files, it's
in two separate places on the disk. The kernel obscures this. It's
not an "arbitrary amount data". The kernel has to access the
directory structure (admittedly) to deal with things like the name
of the file, the file itself, and in the case of these MacOS file
filesystems, the resource fork. The resource fork is an extra
operation *to the disk*: it's stored separately.
The kernel has nothing to do with this..
I'm happy to discuss it further, but lets take it off list from this
point.. I'm sure most people agree..
Evert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Off-topic MacOS resource flaming, was : Re: checking out mac resource forks, file checkout order
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
[ I'm about to flame seriously, and have marked this off-topic. ]
Dave Camp wrote:
> On May 21, 2006, at 10:38 AM, Nico Kadel-Garcia wrote:
>
>> Dave Camp wrote:
>>
>>> I agree that resource forks should be avoided these days, but your
>>> assertions that they are unreliable or slow down the file system are
>>> incorrect.
>>
>> It means that every single filesystem operation, such as read,
>> write, delete, rename, or copy takes twice as m any operations:
>> that means accessing the disk *twice* for a lot of very basic
>> operations. That can and will slow down the most basic operations.
>> Doubling the complexity of such a variety of operations also
>> endangers the filesystem: with twice the number of operations, and
>> those operations tightly cross-linked in such a way that screwing
>> up either of them screws up the actual file desired, you're just
>> begging for file system failures.
>
> The blanket statement that it takes twice as many operations is
> incorrect. Reading an arbitrary amount data is the same as it would
> be on any filesystem. read() seeks to the correct place in the file
> and reads the data. Same for write(). There is nothing special about
> this on HFS+ or with files with resource forks.
Take a look at thedata actually on the disk. It's in two files, it's in two
separate places on the disk. The kernel obscures this. It's not an
"arbitrary amount data". The kernel has to access the directory structure
(admittedly) to deal with things like the name of the file, the file itself,
and in the case of these MacOS file filesystems, the resource fork. The
resource fork is an extra operation *to the disk*: it's stored separately.
> Delete and rename are a single operation on HFS+. There is a single
> entry in the catalog B*tree representing the first two forks of the
> file. Delete and rename would be two operations on other filesystems
> where the resource fork was stored as a separate file.
The B*tree is a way of describing the location of the files: since there are
two different places the information is stored, that means two operations on
two different blocks or sets of blocks. Even for a single empty file.txt
file, that means extra and unnecessary data.
> Copy is similar to delete in that you would deal with a single file
> on HFS+ and two files on other filesystems. However, the amount of
> data to be copied would be the same. That is, if a developer wrote
> code to save all of his data in the data fork instead of putting some
> it in the resource fork, the amount of data in the "file" is the
> same. The only difference how it is contained. The amount of data
> copied is the same in both cases
But it's two different blocks or sets of blocks on the disk! That means two
operations. (OK, I've been ignoring the directory structure ones). And
frankly, for most modern software, the information formerly stored by the
resource fork is not particularly useful. Oh, this program created the file?
Who cares! The system that created the data file may have nothing to do with
the system that receives it, which may have entirely different programs for
opening it.
>> Much of the old resource data, such as associating programs with
>> files, has since been changed to using three-letter suffixes for
>> file types, and this seems to be enough.
>
> You seem to be confusing metadata with resources. They are not the
> same thing. Resource forks were typically used for storing needed
> bits of data for a program, such as icons, UI layout data, strings
> for each language, etc. Metadata, such as file creators, types,
> dates, etc has always been stored in the catalog file itself, at
> least on HFS. On other filesystems, this data was either lost or
> saved in a separate file.
That data is, in most cases, not necessary. Text files or .doc files? Who
cares if the program had a funky icon or UI! And don't get me started on
language data! Yech! What a source of madness and instability!
>> Most of the resource data is, in fact, not used and useless to
>> normal operations.
>
> Again, you seem to have mixed up metadata and resources. Removed the
> resources from most any app that uses resource forks and it will most
> likely not work at all. Again, resources are a way of storing bits of
> data the application needs, not just metadata.
Most of those "resources" were only used in a few circumstances, a source of
endless failure modes and grief, in my experience cleaning up after their
corruption. They had their uses, but those uses were usually better
contained in the program itself. Icons with data files? Who the heck cares
what icon is tied ot a program or file? That is metadata!
> Hope that clears things up a bit. Again, I'm not defending resource
> forks, I agree that getting rid of them is the correct solution, just
> not for the reasons you put forth.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Dave Camp <da...@thinbits.com>.
On May 21, 2006, at 10:38 AM, Nico Kadel-Garcia wrote:
> Dave Camp wrote:
>
>> I agree that resource forks should be avoided these days, but your
>> assertions that they are unreliable or slow down the file system are
>> incorrect.
>
> It means that every single filesystem operation, such as read,
> write, delete, rename, or copy takes twice as m any operations:
> that means accessing the disk *twice* for a lot of very basic
> operations. That can and will slow down the most basic operations.
> Doubling the complexity of such a variety of operations also
> endangers the filesystem: with twice the number of operations, and
> those operations tightly cross-linked in such a way that screwing
> up either of them screws up the actual file desired, you're just
> begging for file system failures.
The blanket statement that it takes twice as many operations is
incorrect. Reading an arbitrary amount data is the same as it would
be on any filesystem. read() seeks to the correct place in the file
and reads the data. Same for write(). There is nothing special about
this on HFS+ or with files with resource forks.
Delete and rename are a single operation on HFS+. There is a single
entry in the catalog B*tree representing the first two forks of the
file. Delete and rename would be two operations on other filesystems
where the resource fork was stored as a separate file.
Copy is similar to delete in that you would deal with a single file
on HFS+ and two files on other filesystems. However, the amount of
data to be copied would be the same. That is, if a developer wrote
code to save all of his data in the data fork instead of putting some
it in the resource fork, the amount of data in the "file" is the
same. The only difference how it is contained. The amount of data
copied is the same in both cases
>> The only problem with file forks is that they are unique to HFS and
>> HFS+. There isn't a good way to represent them on other filesystems
>> and source code that isn't Mac specific doesn't know they exist.
>> Resource forks don't "double-up on file operations" as the data
>> contained in them would have had to have been copied using some other
>> method if resource forks had not been used (e.g. data in a separate
>> data file, data added to the main file, etc).
>
> Yes, but that data would be in *one file*. That means a single disk-
> access, not two.
No. With the (much needed) demise of resource forks, all of the
various bits of data that would have been stored in individual
resources in a single resource fork are now shot-gunned across
hundreds of individual files in a Bundle folder. It's not uncommon
for a single application to be composed of up to a hundred different
files (icons, UI layout, strings, etc). In the past, each one of
those files probably would have been a separate resource in the
resource fork.
> Much of the old resource data, such as associating programs with
> files, has since been changed to using three-letter suffixes for
> file types, and this seems to be enough.
You seem to be confusing metadata with resources. They are not the
same thing. Resource forks were typically used for storing needed
bits of data for a program, such as icons, UI layout data, strings
for each language, etc. Metadata, such as file creators, types,
dates, etc has always been stored in the catalog file itself, at
least on HFS. On other filesystems, this data was either lost or
saved in a separate file.
> Most of the resource data is, in fact, not used and useless to
> normal operations.
Again, you seem to have mixed up metadata and resources. Removed the
resources from most any app that uses resource forks and it will most
likely not work at all. Again, resources are a way of storing bits of
data the application needs, not just metadata.
Hope that clears things up a bit. Again, I'm not defending resource
forks, I agree that getting rid of them is the correct solution, just
not for the reasons you put forth.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Dave Camp wrote:
> I agree that resource forks should be avoided these days, but your
> assertions that they are unreliable or slow down the file system are
> incorrect.
It means that every single filesystem operation, such as read, write,
delete, rename, or copy takes twice as m any operations: that means
accessing the disk *twice* for a lot of very basic operations. That can and
will slow down the most basic operations. Doubling the complexity of such a
variety of operations also endangers the filesystem: with twice the number
of operations, and those operations tightly cross-linked in such a way that
screwing up either of them screws up the actual file desired, you're just
begging for file system failures.
Apple and their developers have worked hard to stabilize this stuff, and to
take advantage of its features that are why they used it in the first place,
but I've found it quite painful to support.
> A resource fork is essentially a database attached to a data file.
> They are two separate files that are managed as one by the
> filesystem. Actually, HFS+ supports an arbitrary number of forks on a
> file, not just two. However, I don't think Apple has used more than
> two historically.
True from my experience.
> The only problem with file forks is that they are unique to HFS and
> HFS+. There isn't a good way to represent them on other filesystems
> and source code that isn't Mac specific doesn't know they exist.
> Resource forks don't "double-up on file operations" as the data
> contained in them would have had to have been copied using some other
> method if resource forks had not been used (e.g. data in a separate
> data file, data added to the main file, etc).
Yes, but that data would be in *one file*. That means a single disk-access,
not two. Much of the old resource data, such as associating programs with
files, has since been changed to using three-letter suffixes for file types,
and this seems to be enough.
Most of the resource data is, in fact, not used and useless to normal
operations.
> In any event, the original poster should just move to data fork
> resource files. It will solve his issues with subversion and cause
> the least disruption to his code base.
I agree with this completely.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Dave Camp <da...@thinbits.com>.
On May 20, 2006, at 12:10 PM, Nico Kadel-Garcia wrote:
> Ryan Schmidt wrote:
>> On May 20, 2006, at 05:25, Nico Kadel-Garcia wrote:
>>
>>>>> 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.
>>
>> Yes, resource forks are a bad idea today, because of the many and
>> varied unexpected situations one can run into when trying to
>> interoperate with software that is not aware of resource forks
>> because it originated on non-Mac systems (not because they corrupt
>> anything, which they don't).
>
> My experience was that they were never that good or reliable of an
> idea in the *first* place. Seriously, it forces the OS to double-up
> on file operations like "copy", "rename", or "move" and creates
> serious adventures. The benefit was minimal, the hazards quite
> serious.
I agree that resource forks should be avoided these days, but your
assertions that they are unreliable or slow down the file system are
incorrect.
A resource fork is essentially a database attached to a data file.
They are two separate files that are managed as one by the
filesystem. Actually, HFS+ supports an arbitrary number of forks on a
file, not just two. However, I don't think Apple has used more than
two historically.
The only problem with file forks is that they are unique to HFS and
HFS+. There isn't a good way to represent them on other filesystems
and source code that isn't Mac specific doesn't know they exist.
Resource forks don't "double-up on file operations" as the data
contained in them would have had to have been copied using some other
method if resource forks had not been used (e.g. data in a separate
data file, data added to the main file, etc).
In any event, the original poster should just move to data fork
resource files. It will solve his issues with subversion and cause
the least disruption to his code base.
Dave
> ---------------------------------------------------------------------
> 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
Re: checking out mac resource forks, file checkout order
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
Ryan Schmidt wrote:
> On May 20, 2006, at 05:25, Nico Kadel-Garcia wrote:
>
>>>> 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.
>
> Yes, resource forks are a bad idea today, because of the many and
> varied unexpected situations one can run into when trying to
> interoperate with software that is not aware of resource forks
> because it originated on non-Mac systems (not because they corrupt
> anything, which they don't).
My experience was that they were never that good or reliable of an idea in
the *first* place. Seriously, it forces the OS to double-up on file
operations like "copy", "rename", or "move" and creates serious adventures.
The benefit was minimal, the hazards quite serious.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 20, 2006, at 05:25, Nico Kadel-Garcia wrote:
>>> 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.
Yes, resource forks are a bad idea today, because of the many and
varied unexpected situations one can run into when trying to
interoperate with software that is not aware of resource forks
because it originated on non-Mac systems (not because they corrupt
anything, which they don't).
>>> 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?
Mac OS X (all versions, as far as I remember) will create
files ._whatever to store resource fork data if the file contains a
resource fork and is copied to a file system like FAT32 or pretty
much anything other than HFS or HFS+ which cannot natively handle
resource forks. I know of no way to disable this "feature."
When I edit PHP source files on our company's Linux server via a
Samba share on my Mac, my text editor TextWrangler (the free version
of BBEdit) adds a resource fork to each file, to store the position
of the window and other settings. These show up on the server as ._
files. I installed a nightly cron job on the server to delete them.
<shrug>
At least Mac OS X's creation of .DS_Store files in every directory
can be suppressed on mounted servers using TinkerTool.
What's new in Mac OS X 10.4 is that the rm, cp, mv and other similar
commands have been modified to simultaneously affect the ._ files.
This is what makes Subversion broken now in this case, and this is
why I suggested 10.3.x or earlier as a workaround.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
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.
Maybe, but that doesn't help people that have to deal with them.
Furthermore, Mac OS X doesn't actually use resource forks any more, it
emulates them with extended attributes, which are available in many
other operating systems. So it is a pretty unfortunate that Subversion
doesn't properly handle them.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: checking out mac resource forks, file checkout order
Posted by Nico Kadel-Garcia <nk...@comcast.net>.
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