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
Received on Wed Jun 1 18:57:31 2005