You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Geoffrey Alan Washburn <ge...@cis.upenn.edu> on 2005/06/01 00:04:41 UTC
Bug in svn on MacOS X
Okay, I'll give it another try. On a partition formatted as UFS
% cd /tmp
% svnadmin create foo
% mkdir bar
% cd bar
% svn co file:///tmp/foo
Checked out revision 0.
% touch baz
% xattr --set qux quux baz
% svn add baz ._baz
A (bin) ._baz
A baz
% svn commit -m "quuux"
Adding (bin) ._baz
Adding baz
Transmitting file data ..
Commited revision 1.
% cd /tmp
% mkdir blorf
% cd blorf
% svn co file:///tmp/foo
Checked out revision 1.
% svn update
svn: Can't copy '.svn/text-base/._baz.svn-base' to
'.svn/tmp/text-base/._baz.svn-base.tmp': No such file or directory
% ls -la .svn/text-base
drwxr-xr-x 2 geoffw wheel 1024 May 31 19:57 ./
drwxr-xr-x 7 geoffw wheel 1024 May 31 19:57 ../
-r--r--r-- 1 geoffw wheel 0 May 32 19:56 baz.svn-base
%
So what exactly is the problem here? Should I file this as a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by James Berry <ja...@jberry.us>.
On Jun 1, 2005, at 8:58 AM, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 10:42 AM, James Berry wrote:
>> Subversion _should_ be made to do this. At that point, the fact
>> that there is a ._file on some file systems should be ignored as
>> an fs implementation detail.
> Not gonna happen. Resource forks are deprecated, Apple recommends
> against using them, and so there's no way Subversion is going to
> grow custom code to deal with them. This has been discussed many
> times before. :-)
Well, don't take my comments to apply only to resource forks.
The fact that OS X now supports extended attributes is good...it
joins a list of other platforms that support the same API for access
to extended metadata for a file. Other information is, and will, be
stored in EAs. The neat thing that Apple did with Tiger (even though
they too have been saying for years "don't worry about resource
forks...they're deprecated") is that they focused on the general
solution (extended attributes) and simply made the resource fork fall
into that category. They then made sure all the other tools (tar,
rsync, etc) supported EAs. And so they've killed multiple birds with
one stone, and along the way created a generic mechanism for getting
at extended file metadata.
So in suggesting that subversion support EAs and ACLs, I'm not
suggesting you support resource forks explicitly, but rather that you
support a generic, cross-platform mechanism for querying/manipulating
extended file metadata. There would seem to be a great mapping
between EAs and subversion properties. This would, implicitly, solve
the resource fork problem, but would also give you a generic way to
support any sort of extended metadata on files using a cross-platform
API. And file metadata, as we all know, is getting more important,
not less.
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 01.06.2005, at 17:58, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 10:42 AM, James Berry wrote:
>>
>> Subversion _should_ be made to do this. At that point, the fact that
>> there is a ._file on some file systems should be ignored as an fs
>> implementation detail.
>
> Not gonna happen. Resource forks are deprecated, Apple recommends
> against using them, and so there's no way Subversion is going to grow
> custom code to deal with them. This has been discussed many times
> before. :-)
._ files can now contain more than just resource forks. As of 10.4,
they can contain a lot of other properties that people might
legitimately want to version, properties which Apple considers
important, which are advertised on the public Apple web site, and which
developers have been asking for, and so it would seem Subversion should
gracefully deal with them. We don't need lots of new features for
dealing natively with ACLs or other properties, but we do need a way to
not throw confusing errors and fail to work properly. You can consider
the behavior of 10.4's kernel to be a bug if you like, but it is
considered by Apple to be a new and nifty feature, and therefore is
unlikely to go away, and I admit that I myself have in the past been
left with many a ._foo when the foo to which it belonged had long since
been rm'ed, and this new feature will prevent that from happening. The
simplest way I see for Subversion to deal with this is to check if
running on 10.4 [1], and if so, when moving or copying a list of files
(or a directory of files in it), simply ignore any file ._foo where a
corresponding foo exists (since the OS will take care of them). And
prevent people from manipulating the repository's ._foo directly if foo
exists.
[1] Apple always warns against changing behavior based on the OS
version; it would be better to find an OS function call or library
whose existence one could test to figure out if this automatic ._
handling is in use.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
>
> On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>
>>> Actually, if Mac users want to store resource forks or extended
>>> attributes in a repository right now, I don't see any reason why
>>> they shouldn't check in the ._ files.
>>
>>
>> Because as the original post that started this thread said, it no
>> longer works in MacOS 10.4.
>
>
> True. I had forgotten about your original post from June [1]. It
> doesn't work anymore as of 10.4, because 10.4 tries to handle the
> situation, and Subversion doesn't realize that a file it thought it was
> handling (the ._ file) has been handled instead by the OS. So you're
> right.
>
>
>>> If people want to use resource forks in Subversion repositories
>>> today, that would be one IMHO reasonable way to do it. Though, as I
>>> mentioned yesterday in another thread, Rez / DeRez may make more
>>> sense, depending maybe on the type of resource.
>>
>>
>> This isn't an option for people that want to store extended attributes.
>
>
> Also true: Rez format is only for resources, not for extended
> attributes. So a solution for storing extended attributes also does not
> exist.
So this brings us back to the point of asking, why are there no plans
to support extended attributes in Subversion? They are a cross-platform
standard, and would make all of these problems go away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
>
> On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>
>>> Actually, if Mac users want to store resource forks or extended
>>> attributes in a repository right now, I don't see any reason why
>>> they shouldn't check in the ._ files.
>>
>>
>> Because as the original post that started this thread said, it no
>> longer works in MacOS 10.4.
>
>
> True. I had forgotten about your original post from June [1]. It
> doesn't work anymore as of 10.4, because 10.4 tries to handle the
> situation, and Subversion doesn't realize that a file it thought it was
> handling (the ._ file) has been handled instead by the OS. So you're
> right.
>
>
>>> If people want to use resource forks in Subversion repositories
>>> today, that would be one IMHO reasonable way to do it. Though, as I
>>> mentioned yesterday in another thread, Rez / DeRez may make more
>>> sense, depending maybe on the type of resource.
>>
>>
>> This isn't an option for people that want to store extended attributes.
>
>
> Also true: Rez format is only for resources, not for extended
> attributes. So a solution for storing extended attributes also does not
> exist.
So this brings us back to the point of asking, why are there no plans
to support extended attributes in Subversion? They are a cross-platform
standard, and would make all of these problems go away.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 23, 2005, at 13:38, Geoffrey Alan Washburn wrote:
>> Actually, if Mac users want to store resource forks or extended
>> attributes in a repository right now, I don't see any reason why
>> they shouldn't check in the ._ files.
>
> Because as the original post that started this thread said, it no
> longer works in MacOS 10.4.
True. I had forgotten about your original post from June [1]. It
doesn't work anymore as of 10.4, because 10.4 tries to handle the
situation, and Subversion doesn't realize that a file it thought it
was handling (the ._ file) has been handled instead by the OS. So
you're right.
>> If people want to use resource forks in Subversion repositories
>> today, that would be one IMHO reasonable way to do it. Though, as
>> I mentioned yesterday in another thread, Rez / DeRez may make
>> more sense, depending maybe on the type of resource.
>
> This isn't an option for people that want to store extended
> attributes.
Also true: Rez format is only for resources, not for extended
attributes. So a solution for storing extended attributes also does
not exist.
[1] http://svn.haxx.se/users/archive-2005-06/0008.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
> Actually, if Mac users want to store resource forks or extended
> attributes in a repository right now, I don't see any reason why they
> shouldn't check in the ._ files.
Because as the original post that started this thread said, it no
longer works in MacOS 10.4.
> If people want to use resource forks in Subversion repositories today,
> that would be one IMHO reasonable way to do it. Though, as I mentioned
> yesterday in another thread, Rez / DeRez may make more sense, depending
> maybe on the type of resource.
This isn't an option for people that want to store extended attributes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Ryan Schmidt wrote:
> Actually, if Mac users want to store resource forks or extended
> attributes in a repository right now, I don't see any reason why they
> shouldn't check in the ._ files.
Because as the original post that started this thread said, it no
longer works in MacOS 10.4.
> If people want to use resource forks in Subversion repositories today,
> that would be one IMHO reasonable way to do it. Though, as I mentioned
> yesterday in another thread, Rez / DeRez may make more sense, depending
> maybe on the type of resource.
This isn't an option for people that want to store extended attributes.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 22, 2005, at 20:58, Wilfredo Sánchez Vega wrote:
> Extended attributes are a well supported feature in Tiger which
> is not deprecated at all. Resource forks are a slightly different
> thing, but both are stored in ._ files.
Well, as you say, only on non-Mac-native filesystems. So, on HFS, HFS
+ and case-sensitive HFS+, the OS won't create any ._ files for you.
> Users should actively avoid storing ._ files in Subversion
> repositories directly. The behavior of these files is not the same
> on HFS+ as UFS, and it would not be prudent at all for Subversion
> to become knowledgeable about them other than to ignore them by
> default.
Actually, if Mac users want to store resource forks or extended
attributes in a repository right now, I don't see any reason why they
shouldn't check in the ._ files.
For example, on my Mac, I access a working copy that's on a Samba
share on a Linux server, so when my Mac creates resource forks on the
Samba share, it creates ._ files on the Linux server. I could check
these in, and they would work great when access over the Samba share
from a Mac.
If I were storing the working copy on my Mac locally, on my HFS+ hard
drive, then I would have to use /Developer/Tools/SplitForks to split
out the resource fork into a ._ file before checking in, and run /
System/Library/CoreServices/FixupResourceForks to recombine them
after checking out.
If people want to use resource forks in Subversion repositories
today, that would be one IMHO reasonable way to do it. Though, as I
mentioned yesterday in another thread, Rez / DeRez may make more
sense, depending maybe on the type of resource.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Wilfredo Sánchez Vega <ws...@wsanchez.net>.
Ben, this isn't entirely correct.
Extended attributes are a well supported feature in Tiger which is
not deprecated at all. Resource forks are a slightly different
thing, but both are stored in ._ files.
First, I think filesystem should be hiding these files now that
the kernel is magically dealing with them. This would mean, however
that attempts to write to a file called ._foo would yield some form
of error (perhaps ENOTSUP). So there is a bit of pollution in the
file namespace, but that's already a problem.
Just FYI, this magic kernel-level "._" file behavior now exists on
*most* filesystems, meaning everything except HFS+, where the magic
is actually supported by the filesystem format. This includes, for
example, NFS.
To clarify the change, in 10.4, the kernel does this magic. The
advantage of that is that the <sys/xattr.h> works uniformly on all
filesystems, the downside being that this magic file stuff is weird
and IMO needs some cleanup. Prior to 10.4, ._ files were handled in
userland, the downside being that only software using CarbonCore (or
CoreFoundation?) could access that data.
The ideal behavior for Subversion would be to map extended
attributes to resource properties and back. Extended attributes and
properties are a good match because both are intended to store small-
buffer-sized chunks of data and behave similarly. Resource forks
remain a bit of a problem because, although I think they can be
accessed by the xattr API, they are not bounded in size and are
accessed using open/read/write functions just like the data fork.
So while, yes, resource forks remain the oddball, I do think it
would be useful and prudent for svn clients to store extended
attributes properly. I also think that WebDAVFS should also be
mapping xattrs to properties and back. There obviously needs to be a
single convention for this. I'd propose that an xattr named "foo" be
mapped to a property named "xattr:foo" and vice versa, the prefix
being useful because not all DAV properties (eg. svn:foo) should be
unmapped to xattrs.
Users should actively avoid storing ._ files in Subversion
repositories directly. The behavior of these files is not the same
on HFS+ as UFS, and it would not be prudent at all for Subversion to
become knowledgeable about them other than to ignore them by default.
-wsv
On Jun 1, 2005, at 8:58 AM, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 10:42 AM, James Berry wrote:
>
>> Subversion _should_ be made to do this. At that point, the fact
>> that there is a ._file on some file systems should be ignored as
>> an fs implementation detail.
>
> Not gonna happen. Resource forks are deprecated, Apple recommends
> against using them, and so there's no way Subversion is going to
> grow custom code to deal with them. This has been discussed many
> times before. :-)
RE: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Jake Robb <ja...@mac.com>.
Ben,
You should read the following:
http://arstechnica.com/reviews/os/macosx-10.4.ars/7
Suffice it to say that while "resource forks" have been deprecated, a
similar component still exists in the filesystem and is apparently going to
become more and more relevant in the future.
I'm guessing that the discussion has not happened in the last month or so
(since April 29, the release date of OS X 10.4), and proposing that it
happen again.
My suspicion is that APR should be extended to support the xattr system in
some portable manner. I'm not familiar enough with APR (or xattr, for that
matter) to elaborate.
-Jake
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Wednesday, June 01, 2005 11:59 AM
To: James Berry
Cc: Subversion List; Ryan Schmidt; Geoffrey Alan Washburn
Subject: Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
On Jun 1, 2005, at 10:42 AM, James Berry wrote:
> Subversion _should_ be made to do this. At that point, the fact
> that there is a ._file on some file systems should be ignored as an
> fs implementation detail.
Not gonna happen. Resource forks are deprecated, Apple recommends
against using them, and so there's no way Subversion is going to grow
custom code to deal with them. This has been discussed many times
before. :-)
---------------------------------------------------------------------
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: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 1, 2005, at 10:42 AM, James Berry wrote:
> Subversion _should_ be made to do this. At that point, the fact
> that there is a ._file on some file systems should be ignored as an
> fs implementation detail.
Not gonna happen. Resource forks are deprecated, Apple recommends
against using them, and so there's no way Subversion is going to grow
custom code to deal with them. This has been discussed many times
before. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by James Berry <ja...@jberry.us>.
On Jun 1, 2005, at 8:31 AM, Ryan Schmidt wrote:
> On 01.06.2005, at 17:20, Ben Collins-Sussman wrote:
>> On Jun 1, 2005, at 4:18 AM, Ryan Schmidt wrote:
>>> I was pretty sure I'd heard from others on this list that they're
>>> using Subversion on 10.4 without problems. But maybe they're not
>>> using any files with a ._ component? or maybe they're not using UFS?
>> Ryan, I just spoke with fitz, who is a former apple guy, and I
>> think your analysis is spot-on. If both 'foo' and '._foo' are in
>> the repository, then 'svn checkout' downloads the files into .svn/
>> tmp/. It then asks APR to move 'foo' into the visible working
>> area... but then the darwin kernel moves *both* files when this
>> happens.
>>
>> This is effectively a 10.4 kernel feature... or bug, depending on
>> how you look at it. APR asks the OS to move a file, and it moves
>> 2 files instead. I don't think there's anything either Subversion
>> or APR can do about this. The only advice is either (1) don't use
>> UFS, or (2) don't put ._foo files under version control (why would
>> you do that anyway?)
>>
>
> Re (1): I'm not convinced it's only a UFS problem. My 10.4 DVD
> arrived today so I'll be able to test this on HFS+ soon.
>
> Re (2): There may be valid reasons to include ._ files in the
> repository. They contain the resource fork, so any files that are
> old-school Mac files that require resource forks would be destroyed
> if the ._ file were not maintained. And since 10.4 now stores even
> more stuff in there (ACL properties for example?) there may now be
> even more reason one would want to version those.
But if subversion were to use the extended attributes functions to
fetch and store the extended attributes along with the file, then
we'd be in heaven. The extended attributes, which include the
resource fork under 10.4, would simply be archived along with the
file. Subversion _should_ be made to do this. At that point, the fact
that there is a ._file on some file systems should be ignored as an
fs implementation detail.
(Note that while I believe ACLs are stored internally as EA's, I
think you have to use additional API to query and set them...but they
should probably be stored too.)
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 01.06.2005, at 17:20, Ben Collins-Sussman wrote:
> On Jun 1, 2005, at 4:18 AM, Ryan Schmidt wrote:
>
>> I was pretty sure I'd heard from others on this list that they're
>> using Subversion on 10.4 without problems. But maybe they're not
>> using any files with a ._ component? or maybe they're not using UFS?
>
> Ryan, I just spoke with fitz, who is a former apple guy, and I think
> your analysis is spot-on. If both 'foo' and '._foo' are in the
> repository, then 'svn checkout' downloads the files into .svn/tmp/.
> It then asks APR to move 'foo' into the visible working area... but
> then the darwin kernel moves *both* files when this happens.
>
> This is effectively a 10.4 kernel feature... or bug, depending on how
> you look at it. APR asks the OS to move a file, and it moves 2 files
> instead. I don't think there's anything either Subversion or APR can
> do about this. The only advice is either (1) don't use UFS, or (2)
> don't put ._foo files under version control (why would you do that
> anyway?)
Re (1): I'm not convinced it's only a UFS problem. My 10.4 DVD arrived
today so I'll be able to test this on HFS+ soon.
Re (2): There may be valid reasons to include ._ files in the
repository. They contain the resource fork, so any files that are
old-school Mac files that require resource forks would be destroyed if
the ._ file were not maintained. And since 10.4 now stores even more
stuff in there (ACL properties for example?) there may now be even more
reason one would want to version those.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Wed, 2005-06-01 at 14:46 -0400, Geoffrey Alan Washburn wrote:
> Brian W. Fitzpatrick wrote:
> > On 6/1/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> >
> >
> >>So if we say that someone might legitimately want to check in a ._
> >>file, how would she do so? Would she have to put her working copy on a
> >>non-HFS+ partition or disk image? That seems awfully cumbersome
> >>(although maybe that is the solution).
> >
> >
> > The recommended solution here is to use the DeRez and Rez utilities in
> > /Developer/Tools/.
>
> That would certainly be a reasonable interim solution. Thanks. Does
> anyone have any experience on automating this to any extent?
>
> I agree with the others that in a future version, POSIX extended
> attributes should be mapped to Subversion properties. Resource forks
> may be depreciated, but extended attributes are going to be important to
> support, and it isn't going to be just a MacOS X problem.
I agree. xattrs seem like a perfect marriage for Subversion properties.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Scott Palmer <sc...@2connected.org>.
On Jun 1, 2005, at 3:23 PM, Brian W. Fitzpatrick wrote:
> On Wed, 2005-06-01 at 14:46 -0400, Geoffrey Alan Washburn wrote:
>
>> Brian W. Fitzpatrick wrote:
>>
>> I agree with the others that in a future version, POSIX extended
>> attributes should be mapped to Subversion properties. Resource forks
>> may be depreciated, but extended attributes are going to be
>> important to
>> support, and it isn't going to be just a MacOS X problem.
>>
>
> I agree. xattrs seem like a perfect marriage for Subversion
> properties.
+1
I am against the general hacking of the Mac resource fork, but a
cross-platform mechanism for metadata will be great. If xattr is
that mechanism for the unix-ish operating systems than it would be
great for Subversion to support it. No doubt Microsoft will pretend
to invent their own system for metadata, but I imagine that it too
will boil down to simple named properties and therefore it makes
sense that the APR layer would be able to interface to it as well.
The previous comments of leaving the metadata intact in the repo if
the host FS does not support it in the WC appears to make good sense
too.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Wed, 2005-06-01 at 14:46 -0400, Geoffrey Alan Washburn wrote:
> Brian W. Fitzpatrick wrote:
> > On 6/1/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> >
> >
> >>So if we say that someone might legitimately want to check in a ._
> >>file, how would she do so? Would she have to put her working copy on a
> >>non-HFS+ partition or disk image? That seems awfully cumbersome
> >>(although maybe that is the solution).
> >
> >
> > The recommended solution here is to use the DeRez and Rez utilities in
> > /Developer/Tools/.
>
> That would certainly be a reasonable interim solution. Thanks. Does
> anyone have any experience on automating this to any extent?
>
> I agree with the others that in a future version, POSIX extended
> attributes should be mapped to Subversion properties. Resource forks
> may be depreciated, but extended attributes are going to be important to
> support, and it isn't going to be just a MacOS X problem.
I agree. xattrs seem like a perfect marriage for Subversion properties.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Brian W. Fitzpatrick wrote:
> On 6/1/05, Ryan Schmidt <su...@ryandesign.com> wrote:
>
>
>>So if we say that someone might legitimately want to check in a ._
>>file, how would she do so? Would she have to put her working copy on a
>>non-HFS+ partition or disk image? That seems awfully cumbersome
>>(although maybe that is the solution).
>
>
> The recommended solution here is to use the DeRez and Rez utilities in
> /Developer/Tools/.
That would certainly be a reasonable interim solution. Thanks. Does
anyone have any experience on automating this to any extent?
I agree with the others that in a future version, POSIX extended
attributes should be mapped to Subversion properties. Resource forks
may be depreciated, but extended attributes are going to be important to
support, and it isn't going to be just a MacOS X problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Brian W. Fitzpatrick wrote:
> On 6/1/05, Ryan Schmidt <su...@ryandesign.com> wrote:
>
>
>>So if we say that someone might legitimately want to check in a ._
>>file, how would she do so? Would she have to put her working copy on a
>>non-HFS+ partition or disk image? That seems awfully cumbersome
>>(although maybe that is the solution).
>
>
> The recommended solution here is to use the DeRez and Rez utilities in
> /Developer/Tools/.
That would certainly be a reasonable interim solution. Thanks. Does
anyone have any experience on automating this to any extent?
I agree with the others that in a future version, POSIX extended
attributes should be mapped to Subversion properties. Resource forks
may be depreciated, but extended attributes are going to be important to
support, and it isn't going to be just a MacOS X problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by "Brian W. Fitzpatrick" <bw...@gmail.com>.
On 6/1/05, Ryan Schmidt <su...@ryandesign.com> wrote:
> So if we say that someone might legitimately want to check in a ._
> file, how would she do so? Would she have to put her working copy on a
> non-HFS+ partition or disk image? That seems awfully cumbersome
> (although maybe that is the solution).
The recommended solution here is to use the DeRez and Rez utilities in
/Developer/Tools/.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Scott Palmer <sc...@2connected.org>.
On Jun 2, 2005, at 2:22 PM, Geoffrey Alan Washburn wrote:
> Jake Robb wrote:
>
>
>> It sounds to me like this idea has some support, and I'm thinking
>> it's
>> likely that extended attributes will be a new feature in an upcoming
>> version. However, since I have absolutely nothing to do with
>> Subversion
>> development, my opinion doesn't count for much. :-)
>>
>
> Indeed. It isn't clear to me that any of the developers have
> actually committed to the idea. Mapping xattrs to properties
> probably should be pretty easy, so I may look at it myself in some
> hypothetical future. However, even if I did so it would be nice to
> know whether such patches would even be accepted.
I was under the impression that properties are not stored as diffs in
the repository, and in general the value of a property should be
"small". This to me still seems like it fits with the general idea
of xattrs, but the more generic multiple data streams for a single
file (e.g. the deprecated resource forks) wouldn't be nearly as well
suited to being stored in properties.
Thankfully, since resource forks are deprecated, it likely doesn't
matter. I'm guessing the most straight-forward implementation of
storing xattrs as subversion properties would suffice, at least for
the initial implementation.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Geoffrey Alan Washburn <ge...@cis.upenn.edu>.
Jake Robb wrote:
> It sounds to me like this idea has some support, and I'm thinking it's
> likely that extended attributes will be a new feature in an upcoming
> version. However, since I have absolutely nothing to do with Subversion
> development, my opinion doesn't count for much. :-)
Indeed. It isn't clear to me that any of the developers have actually
committed to the idea. Mapping xattrs to properties probably should be
pretty easy, so I may look at it myself in some hypothetical future.
However, even if I did so it would be nice to know whether such patches
would even be accepted.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Scott Palmer <sc...@2connected.org>.
On Jun 2, 2005, at 10:08 AM, Vincent Lefevre wrote:
> You're saying that someone may want to check in a ._ file. This can
> be done on a non-HFS+ partition. But someone who will check out that
> on a HFS+ partition will probably get an error or some other kind of
> clash, because ._ files are handled in a special way there.
>
> What I'm thinking of is that there's the same kind of problems with
> case-insensitive file systems. If someone checks in "foo" and "Foo"
> from a case-sensitive file system, what happens when one checks out
> these files on a case-insensitive file system?
It fails in a very ugly way.
> Does Subversion have
> some workaround and could it be used for ._ files (on HFS+) too?
No.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Jake Robb <ja...@mac.com>.
This is exactly the reason that Apple recommends that developers ignore ._
files as a filesystem implementation detail. OS routines exist which allow
the developer to query and modify a file's extended attributes, regardless
of whether it's a second fork in an HFS+ file, or a ._ file on UFS. If
Subversion is to be able to properly handle ._ files on OS X, it MUST
support the extended attributes (xattr) system.
It sounds to me like this idea has some support, and I'm thinking it's
likely that extended attributes will be a new feature in an upcoming
version. However, since I have absolutely nothing to do with Subversion
development, my opinion doesn't count for much. :-)
At this time, I think that files with nontrivial resource forks (or other
extended attributes) should be managed outside of Subversion. I haven't
heard any good method to preserve them in the repository. Anyone?
-Jake
-----Original Message-----
From: Vincent Lefevre [mailto:vincent+svn@vinc17.org]
Sent: Thursday, June 02, 2005 10:08 AM
To: users@subversion.tigris.org
Subject: Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
On 2005-06-02 14:39:11 +0200, Ryan Schmidt wrote:
> On 02.06.2005, at 13:57, Vincent Lefevre wrote:
>
> >On 2005-06-01 18:37:38 +0200, Ryan Schmidt wrote:
> >
> >>So if we say that someone might legitimately want to check in a ._
> >>file, how would she do so? Would she have to put her working copy on
> >>a non-HFS+ partition or disk image?
> >
> >Aren't there similar problems with case-insensitive file systems?
>
> Sorry, I don't think I follow what you're asking....
You're saying that someone may want to check in a ._ file. This can
be done on a non-HFS+ partition. But someone who will check out that
on a HFS+ partition will probably get an error or some other kind of
clash, because ._ files are handled in a special way there.
What I'm thinking of is that there's the same kind of problems with
case-insensitive file systems. If someone checks in "foo" and "Foo"
from a case-sensitive file system, what happens when one checks out
these files on a case-insensitive file system? Does Subversion have
some workaround and could it be used for ._ files (on HFS+) too?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
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: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-06-02 14:39:11 +0200, Ryan Schmidt wrote:
> On 02.06.2005, at 13:57, Vincent Lefevre wrote:
>
> >On 2005-06-01 18:37:38 +0200, Ryan Schmidt wrote:
> >
> >>So if we say that someone might legitimately want to check in a ._
> >>file, how would she do so? Would she have to put her working copy on
> >>a non-HFS+ partition or disk image?
> >
> >Aren't there similar problems with case-insensitive file systems?
>
> Sorry, I don't think I follow what you're asking....
You're saying that someone may want to check in a ._ file. This can
be done on a non-HFS+ partition. But someone who will check out that
on a HFS+ partition will probably get an error or some other kind of
clash, because ._ files are handled in a special way there.
What I'm thinking of is that there's the same kind of problems with
case-insensitive file systems. If someone checks in "foo" and "Foo"
from a case-sensitive file system, what happens when one checks out
these files on a case-insensitive file system? Does Subversion have
some workaround and could it be used for ._ files (on HFS+) too?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 02.06.2005, at 13:57, Vincent Lefevre wrote:
> On 2005-06-01 18:37:38 +0200, Ryan Schmidt wrote:
>
>> So if we say that someone might legitimately want to check in a ._
>> file, how would she do so? Would she have to put her working copy on
>> a non-HFS+ partition or disk image?
>
> Aren't there similar problems with case-insensitive file systems?
Sorry, I don't think I follow what you're asking....
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-06-01 18:37:38 +0200, Ryan Schmidt wrote:
> So if we say that someone might legitimately want to check in a ._
> file, how would she do so? Would she have to put her working copy on
> a non-HFS+ partition or disk image?
Aren't there similar problems with case-insensitive file systems?
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by James Berry <ja...@jberry.us>.
On Jun 1, 2005, at 9:54 AM, Jake Robb wrote:
> A method should be made available for users to query (and probably
> change)
> the metadata on a file in the repository, such that this data is not
> completely hidden from users whose filesystems don't support it.
Extended attributes should == subversion properties. On Mac OS X (or
other EA enabled system), a subversion property such as svn:eol-style
could be written to the file as the extended attribute
org.tigris.subversion:eol-style (or whatever, or just left as svn:).
In this way extended attributes are versioned just as file data is,
and just as properties are.
A interesting thing about this is that you could even imagine being
able to manipulate subversion properties directly on the file system
object itself (xattr --set svn:eol-style..., or something) and know
that subversion would get and respond to the change. (This might, of
course, blow subversion's mind ;).
-jdb
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Jake Robb <ja...@mac.com>.
Ryan,
The proper solution, IMHO, is this:
1. A future version of Subversion implements a method to support arbitrary
file metadata.
a. This method must be compatible with xattr when used on OS X.
2. You commit a TextWrangler file to the repository. Subversion reads and
stores the attributes, including the resource fork data.
3. Windows User checks out the file. His filesystem does not support
extended attributes, so they are not written to his working copy.
a. Windows User makes modifications to the file
4. Windows User commits his changes. Since his filesystem does not support
extended attributes, no changes are made to the extended attributes of the
file in the repository.
5. You run an Update on the file. You receive an updated version with
changes made by Windows User, and with the attributes as they were when you
committed the file.
On any system where the filesystem supports arbitrary file metadata, the
client will send and receive file metadata, and it will be edited in the
repository upon commit. On any system where the metadata is not supported,
it will not be delivered on checkout/update, and it will not be modified on
commit/import.
It will be the responsibility of editor programs (TextWrangler, for
instance, or any other editor) to properly maintain the file metadata. For
instance, if I open your TextWrangler file in XCode and edit it, you should
expect that your TextWrangler metadata will remain in place, unless XCode's
and TextWrangler's metadata properties have a naming conflict. Since Apple
recommends naming metadata with the hyphenated reverse DNS technique
(com-apple-xcode-setting-name), conflicts should be rare. Subversion should
not concern itself with metadata changes any more than it does with file
changes -- previous revisions should always be available in the repository
anyway, including changes to metadata.
A method should be made available for users to query (and probably change)
the metadata on a file in the repository, such that this data is not
completely hidden from users whose filesystems don't support it.
-Jake
-----Original Message-----
From: Ryan Schmidt [mailto:subversion-2005@ryandesign.com]
Sent: Wednesday, June 01, 2005 12:38 PM
To: Jake Robb
Cc: 'Subversion List'
Subject: Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
On 01.06.2005, at 17:33, Jake Robb wrote:
> Question: if I'm using HFS+ on OS X (which does support multiple data
> streams), and I commit a file with multiple data streams, will
> Subversion
> commit all streams, or just the first one? If only the first stream is
> committed, then this is the actual issue at hand. Subversion should
> commit
> all streams, regardless of which filesystem is being used.
Thanks -- this clarifies why this issue hasn't shown up for the
majority of OS X users, who use HFS+: HFS+ doesn't use ._ files because
the resource fork is handled by HFS+. And when you "svn add foo", only
the data fork of foo ever gets added. Sorry if everyone else "got" this
already; I've had a tired day.
So if we say that someone might legitimately want to check in a ._
file, how would she do so? Would she have to put her working copy on a
non-HFS+ partition or disk image? That seems awfully cumbersome
(although maybe that is the solution). And what about what I would
consider the majority case, where she does not want to check in the ._
file, even in the presence of a resource fork or extra properties? I
use TextWrangler to edit my code, which, like it or not, adds resource
forks to store window position, text selection, and so on. The
Windows-based developers with whom I work sure as heck don't want a
zillion ._ files in their working copies. I currently put "._*" in my
ignore list (and maybe that would continue to suffice).
Just thinking out loud.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 01.06.2005, at 17:33, Jake Robb wrote:
> Question: if I'm using HFS+ on OS X (which does support multiple data
> streams), and I commit a file with multiple data streams, will
> Subversion
> commit all streams, or just the first one? If only the first stream is
> committed, then this is the actual issue at hand. Subversion should
> commit
> all streams, regardless of which filesystem is being used.
Thanks -- this clarifies why this issue hasn't shown up for the
majority of OS X users, who use HFS+: HFS+ doesn't use ._ files because
the resource fork is handled by HFS+. And when you "svn add foo", only
the data fork of foo ever gets added. Sorry if everyone else "got" this
already; I've had a tired day.
So if we say that someone might legitimately want to check in a ._
file, how would she do so? Would she have to put her working copy on a
non-HFS+ partition or disk image? That seems awfully cumbersome
(although maybe that is the solution). And what about what I would
consider the majority case, where she does not want to check in the ._
file, even in the presence of a resource fork or extra properties? I
use TextWrangler to edit my code, which, like it or not, adds resource
forks to store window position, text selection, and so on. The
Windows-based developers with whom I work sure as heck don't want a
zillion ._ files in their working copies. I currently put "._*" in my
ignore list (and maybe that would continue to suffice).
Just thinking out loud.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Jake Robb <ja...@mac.com>.
._ files can contain important file content. They provide the multiple data
stream functionality on filesystems which do not support multiple data
streams. Since the file ._foo.c is technically supposed to be *part* of the
parent file foo.c, I think it's completely reasonable to want it under
version control. (not that .c files are a good example of files with
multiple data streams)
Question: if I'm using HFS+ on OS X (which does support multiple data
streams), and I commit a file with multiple data streams, will Subversion
commit all streams, or just the first one? If only the first stream is
committed, then this is the actual issue at hand. Subversion should commit
all streams, regardless of which filesystem is being used.
-Jake
-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Wednesday, June 01, 2005 11:20 AM
To: Ryan Schmidt
Cc: Geoffrey Alan Washburn; Subversion List
Subject: Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
On Jun 1, 2005, at 4:18 AM, Ryan Schmidt wrote:
>
> I was pretty sure I'd heard from others on this list that they're
> using Subversion on 10.4 without problems. But maybe they're not
> using any files with a ._ component? or maybe they're not using UFS?
>
Ryan, I just spoke with fitz, who is a former apple guy, and I think
your analysis is spot-on. If both 'foo' and '._foo' are in the
repository, then 'svn checkout' downloads the files into .svn/tmp/.
It then asks APR to move 'foo' into the visible working area... but
then the darwin kernel moves *both* files when this happens.
This is effectively a 10.4 kernel feature... or bug, depending on how
you look at it. APR asks the OS to move a file, and it moves 2 files
instead. I don't think there's anything either Subversion or APR can
do about this. The only advice is either (1) don't use UFS, or (2)
don't put ._foo files under version control (why would you do that
anyway?)
---------------------------------------------------------------------
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: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jun 1, 2005, at 4:18 AM, Ryan Schmidt wrote:
>
> I was pretty sure I'd heard from others on this list that they're
> using Subversion on 10.4 without problems. But maybe they're not
> using any files with a ._ component? or maybe they're not using UFS?
>
Ryan, I just spoke with fitz, who is a former apple guy, and I think
your analysis is spot-on. If both 'foo' and '._foo' are in the
repository, then 'svn checkout' downloads the files into .svn/tmp/.
It then asks APR to move 'foo' into the visible working area... but
then the darwin kernel moves *both* files when this happens.
This is effectively a 10.4 kernel feature... or bug, depending on how
you look at it. APR asks the OS to move a file, and it moves 2 files
instead. I don't think there's anything either Subversion or APR can
do about this. The only advice is either (1) don't use UFS, or (2)
don't put ._foo files under version control (why would you do that
anyway?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Bug in svn on MacOS X 10.4 with ._ files on UFS
Posted by Ryan Schmidt <su...@ryandesign.com>.
On 01.06.2005, at 02:04, Geoffrey Alan Washburn wrote:
> Okay, I'll give it another try. On a partition formatted as UFS
>
> % cd /tmp
> % svnadmin create foo
> % mkdir bar
> % cd bar
> % svn co file:///tmp/foo
> Checked out revision 0.
> % touch baz
> % xattr --set qux quux baz
> % svn add baz ._baz
> A (bin) ._baz
> A baz
> % svn commit -m "quuux"
> Adding (bin) ._baz
> Adding baz
> Transmitting file data ..
> Commited revision 1.
> % cd /tmp
> % mkdir blorf
> % cd blorf
> % svn co file:///tmp/foo
> Checked out revision 1.
> % svn update
> svn: Can't copy '.svn/text-base/._baz.svn-base' to
> '.svn/tmp/text-base/._baz.svn-base.tmp': No such file or directory
> % ls -la .svn/text-base
> drwxr-xr-x 2 geoffw wheel 1024 May 31 19:57 ./
> drwxr-xr-x 7 geoffw wheel 1024 May 31 19:57 ../
> -r--r--r-- 1 geoffw wheel 0 May 32 19:56 baz.svn-base
> %
>
> So what exactly is the problem here? Should I file this as a bug?
You mentioned earlier this was on 10.4, which I believe is critical.
My 10.4 DVD hasn't arrived yet, but I've read that the shell commands
"rm", "cp" and so on have been enhanced in 10.4 so that they know how
to deal with these ._ files. So if you have baz and ._baz and you rm
baz, then ._baz will be removed as well. I'm wondering if maybe it's
not just the shell commands that have been enhanced, but whatever
system library those shell commands use, and thus also the system
library that Subversion would end up using. This would mean that as
soon as Subversion tries to move baz from text-base, ._baz would be
moved at the same time, and when a moment later Subversion tries to
separately move ._baz, it doesn't work because it's already gone. You
could check whether this is so by seeing whether the ._baz file exists
in /tmp/blorf. If it is, then Subversion may simply need to filter ._
files out of its list of things to move on 10.4+ and let the OS handle
it.
To try to narrow down the problem, I'd recommend trying this on an HFS+
volume on 10.4, and on a UFS volume on 10.3. I can possibly test the
latter in a day or two if I can find a spare drive.
I was pretty sure I'd heard from others on this list that they're using
Subversion on 10.4 without problems. But maybe they're not using any
files with a ._ component? or maybe they're not using UFS?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org