[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bug in svn on MacOS X 10.4 with ._ files on UFS

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-06-01 18:37:38 CEST

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:48:43 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.