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

Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)

From: Branko Čibej <brane_at_xbc.nu>
Date: 2005-08-16 18:55:14 CEST

Vincent Lefevre wrote:

>On 2005-08-14 15:48:11 +0200, Branko Čibej wrote:
>
>
>>Vincent Lefevre wrote:
>>
>>
>>>Yes, as properties. Isn't this similar to symlink support?
>>>
>>>
>>>
>>No, symlinks are represented as files, not as properties.
>>
>>
>
>Well, with an additional svn:special property. I meant that even
>though symlinks are not supported by some file systems, there's
>a way so that Subversion behaves in a sensible way.
>
>
Of course, but in the case of symlinks, there's no question about what
file name to use when creating tha "link" on a filesystem that doesn't
support symlinks.

Resource forks are a different animal, since the filename of a resource
fork is the same as the name of the file it belongs to.

>>>Another solution would be to use filenames with '$' since they
>>>are forbidden in Subversion.
>>>
>>>
>>>
>>Huh? Since when?
>>
>>
>
>--------------------
>Date: Wed, 06 Jul 2005 10:08:51 -0400
>From: John Peacock <jpeacock@rowman.com>
>To: Vincent Lefevre <vincent+svn@vinc17.org>
>CC: dev@subversion.tigris.org, users@subversion.tigris.org
>Subject: Re: Spaces in Keyword Expansion
>
>[...]
>Don't do that (including '$' in a filename).
>[...]
>
>
So what?

>> $ svnadmin create repo
>> $ svn co file:///H:/brane/src/svn/scratch/repo wc
>> Checked out revision 0.
>> $ cd wc/
>> $ touch '$foo'
>> $ svn add '$foo'
>> A $foo
>> $ svn ci -m ''
>> Adding $foo
>> Transmitting file data .
>> Committed revision 1.
>> $ svn ls -v file:///H:/brane/src/svn/scratch/repo
>> 1 brane 0 Aug 14 15:45 $foo
>>
>>
>This could be seen as a bug.
>
>Otherwise, if $ is really supposed to be supported in filenames,
>what happens to the Id keyword?
>
>
Well, this particular combination is problematic, of course. But that
doesn't mean SVN doesn't support '$' in filenames, it just means that
our keyword expansion/parsing code should be smart enough to escape
them, and if there's a bug, it's there.

OTOH our policy could simply be "don't do that". I don't actually know
what it is, though...

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 16 18:56:00 2005

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

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