You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Eric Gorr <ma...@ericgorr.net> on 2005/08/13 18:34:28 UTC
Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Branko Čibej wrote:
> Eric Gorr wrote:
>
>>> Paul Sturm wrote:
>>>
>>>> I would like to volunteer to implement support for Mac OS X
>>>> "resource forks".
>>>
>>>
>>
>> There is no need to add a feature which solely supports Mac resource
>> forks, which is a good thing since it should never happen. As I
>> understand it, Resource forks are now fully within the POSIX xattr
>> (extended attributes for files) standard - at least starting with
>> MacOSX 10.4. So, if subversion supported xattrs, support resource
>> forks would simply be apart of this and would have applications far
>> beyond simple resource forks and likely increasingly useful on all
>> platforms Subversion runs on - including Windows.
>
>
> There are many filesystems that don't support extended attributes or
> several data streams per file.
Which is entirely irrelevent.
Again, based on my understanding, support for extended attributes will
be 'increasingly useful'. If some file system does not support such
things, it really isn't a problem...subversion can just not look for
such things on those file systems.
>>> So my first question is, is anyone already doing this?
>>
>> As far as I know, noone is working on adding xattr support.
>>
>> The aspect that makes implementing xattr support a bit easier is that
>> there is apparently a 1-1 mapping with the subversion file properties
>> feature.
>>
>> Search the archives for xattr for a little more information
>
> I don't think you can use properties for xattrs at the moment. The
> practical constraints on property sizes are much stricter than on file
> contents.
I am curious, why are the constraints on property sizes 'practical'?
Why would it not be reasonable to increase the allowed size?
If it is not practical to use subversion file property features, then I
suppose some other method would be needed to better support large sized
file metadata.
The point is, there is someone willing to volunteer to implement this
extremely useful feature for those filesystems which do support extended
attributes. It is the sole reason why using subversion is not practical
at least in my specific case.
--
== Eric Gorr ========= http://www.ericgorr.net ========= ICQ:9293199 ==
"Those who would sacrifice a little freedom for temporal safety
deserve neither to be safe or free." -- Benjamin Frankli
== Insults, like violence, are the last refuge of the incompetent... ===
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 18 August 2005 08:45, Branko Čibej wrote:
> Ph. Marek wrote:
> >Excuse me, but I don't seem to understand you.
> >How does that "break" the repository? There's something inconsistent
> > stored - but that's easily repaired.
>
> It's not easily repaired if it means changing properties on a bunch of
> files.
Then let's store pathnames relative to an attribute stored at the repos url.
OK?
> >>>If the /resource-forks path is defined (eg as attribute on REPOS_URL),
> >>> the attributs could be relative to that path - renaming this path would
> >>> take another propset, and everythings ok.
> >>
> >>No, a client that's not aware of this convention won't change the prop,
> >>and will break the repository.
> >
> >A client not aware of this convention won't know how to get or store
> >resource-forks, too, so they will just stay ignored.
>
> It will break the meaning of the repository for clients which _are_
> aware of resource forks.
Why? A non-aware client will update _only_ the data of the file itself, and
should not drop properties at will. So the pointer will stay the same, and as
a non-aware client doesn't know about resource-forks, they just keep the old
value.
If the property gets deleted, well, you get what you deserve :|
BTW, I'd say "don't do that, then", and if it happens, "do a reverse merge".
That's what subversion is for :-)
Sorry - I seem too dense to understand the problems you describe. IMO a
fork-aware-client can update them, and a non-aware-client should ignore them
(that means no modifying or deleting).
Where does your opinion differ?
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
>On Thursday 18 August 2005 08:18, Branko Čibej wrote:
>
>
>>Ph. Marek wrote:
>>
>>
>>>On Wednesday 17 August 2005 23:05, Branko Čibej wrote:
>>>
>>>
>>>>Ph. Marek wrote:
>>>>
>>>>
>>>>>On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
>>>>>
>>>>>
>>>>>> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
>>>>>> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
>>>>>> not aware of the convention?
>>>>>>
>>>>>>
>>>>>As you only change the *name* of something, the attributes describing
>>>>>where to find the resource-forks stay the same.
>>>>>
>>>>>
>>>>You missed the point here -- this is renaming the directory where the
>>>>resource forks files are stored.
>>>>
>>>>
>>>Oh, I see.
>>>Yes, you're right.
>>>That could be a problem.
>>>But I see that on the same lane as
>>> svn mv REPOS_URL/trunk REPOS_URL/something-else
>>>ie. an operation which is guaranteed to make troubles :-)
>>>
>>>
>>It is a completely different kind of problem, because it doesn't break
>>the repository.
>>
>>
>Excuse me, but I don't seem to understand you.
>How does that "break" the repository? There's something inconsistent stored -
>but that's easily repaired.
>
>
It's not easily repaired if it means changing properties on a bunch of
files.
>>>If the /resource-forks path is defined (eg as attribute on REPOS_URL), the
>>>attributs could be relative to that path - renaming this path would take
>>>another propset, and everythings ok.
>>>
>>>
>>No, a client that's not aware of this convention won't change the prop,
>>and will break the repository.
>>
>>
>A client not aware of this convention won't know how to get or store
>resource-forks, too, so they will just stay ignored.
>
>
It will break the meaning of the repository for clients which _are_
aware of resource forks.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Thursday 18 August 2005 08:18, Branko Čibej wrote:
> Ph. Marek wrote:
> >On Wednesday 17 August 2005 23:05, Branko Čibej wrote:
> >>Ph. Marek wrote:
> >>>On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> >>>> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
> >>>> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
> >>>> not aware of the convention?
> >>>
> >>>As you only change the *name* of something, the attributes describing
> >>>where to find the resource-forks stay the same.
> >>
> >>You missed the point here -- this is renaming the directory where the
> >>resource forks files are stored.
> >
> >Oh, I see.
> >Yes, you're right.
> >That could be a problem.
> >But I see that on the same lane as
> > svn mv REPOS_URL/trunk REPOS_URL/something-else
> >ie. an operation which is guaranteed to make troubles :-)
>
> It is a completely different kind of problem, because it doesn't break
> the repository.
Excuse me, but I don't seem to understand you.
How does that "break" the repository? There's something inconsistent stored -
but that's easily repaired.
> >If the /resource-forks path is defined (eg as attribute on REPOS_URL), the
> >attributs could be relative to that path - renaming this path would take
> >another propset, and everythings ok.
>
> No, a client that's not aware of this convention won't change the prop,
> and will break the repository.
A client not aware of this convention won't know how to get or store
resource-forks, too, so they will just stay ignored.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-08-18 08:18:59 +0200, Branko Čibej wrote:
> Ph. Marek wrote:
> >On Wednesday 17 August 2005 23:05, Branko Čibej wrote:
> >>Ph. Marek wrote:
> >>>On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> >>>> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
> >>>> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
> >>>> not aware of the convention?
> >>>>
> >>>As you only change the *name* of something, the attributes describing
> >>>where to find the resource-forks stay the same.
> >>>
> >>You missed the point here -- this is renaming the directory where the
> >>resource forks files are stored.
> >>
> >Oh, I see.
> >Yes, you're right.
> >That could be a problem.
> >But I see that on the same lane as
> > svn mv REPOS_URL/trunk REPOS_URL/something-else
> >ie. an operation which is guaranteed to make troubles :-)
> >
> It is a completely different kind of problem, because it doesn't break
> the repository.
svn mv REPOS_URL/macos-resource-forks REPOS_URL/macos-rsrc
doesn't break the repository either. Clients that aren't aware of
resource forks won't see any different. Clients that are aware of
resource forks should be written to detect a possible problem (e.g.
missing macos-resource-forks directory) and should be able to
ignore resource forks (and let the user correct the repository)
until things are fixed.
This is a bit similar to "svn remove REPOS_URL/trunk", where you
can't do anything useful until some user restores the trunk.
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
>On Wednesday 17 August 2005 23:05, Branko Čibej wrote:
>
>
>>Ph. Marek wrote:
>>
>>
>>>On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
>>>
>>>
>>>> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
>>>> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
>>>> not aware of the convention?
>>>>
>>>>
>>>As you only change the *name* of something, the attributes describing
>>>where to find the resource-forks stay the same.
>>>
>>>
>>You missed the point here -- this is renaming the directory where the
>>resource forks files are stored.
>>
>>
>Oh, I see.
>Yes, you're right.
>That could be a problem.
>But I see that on the same lane as
> svn mv REPOS_URL/trunk REPOS_URL/something-else
>ie. an operation which is guaranteed to make troubles :-)
>
>
It is a completely different kind of problem, because it doesn't break
the repository.
>If the /resource-forks path is defined (eg as attribute on REPOS_URL), the
>attributs could be relative to that path - renaming this path would take
>another propset, and everythings ok.
>
>
No, a client that's not aware of this convention won't change the prop,
and will break the repository.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Wednesday 17 August 2005 23:05, Branko Čibej wrote:
> Ph. Marek wrote:
> >On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> >> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
> >> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
> >> not aware of the convention?
> >
> >As you only change the *name* of something, the attributes describing
> > where to find the resource-forks stay the same.
>
> You missed the point here -- this is renaming the directory where the
> resource forks files are stored.
Oh, I see.
Yes, you're right.
That could be a problem.
But I see that on the same lane as
svn mv REPOS_URL/trunk REPOS_URL/something-else
ie. an operation which is guaranteed to make troubles :-)
If the /resource-forks path is defined (eg as attribute on REPOS_URL), the
attributs could be relative to that path - renaming this path would take
another propset, and everythings ok.
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-08-17 12:09:09 +0200, Ph. Marek wrote:
> On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> > * There's no guarantee that the names will be unique.
> You're right. But there are people relying on hashes being unique
> (apart from really _searching_ for duplicates). If you need more
> security, append a SHA-512 to the MD5 :-) [1] [2]
Why SHA-512 or whatever instead of a value based of the date and time
of the commit + information identifying the committer, a bit like how
Message-Ids are formed, or some random filename? Even in the very rare
cases where the name is not unique, the commit would fail and another
one one could be tried.
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
>On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
>
>
>> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
>> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
>> not aware of the convention?
>>
>>
>As you only change the *name* of something, the attributes describing where to
>find the resource-forks stay the same.
>
>
You missed the point here -- this is renaming the directory where the
resource forks files are stored.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
On Wednesday 17 August 2005 11:23, Branko Čibej wrote:
> Ph. Marek wrote:
> >Regarding the way resource forks and xattrs could be done in the
> > repository I'd like to present an idea.
> >
> >First I assume the standard layout in the repository -
> > /trunk
> > /tags
> > /branches
> >
> >Then there is some file, say
> > /trunk/dir/file
> >
> >When this gets committed from a resource-fork-aware machine, the pathname
> > in the repository gets hashed to a md5-sum:
> > $ echo -n "/trunk/dir/file" | md5sum
> > 71523811009e11f8674bda76bfe2bc93
> >
> >So a complete tree of forks/attributes can be stored in eg.
> > /macos-resource-forks/71/52/3811009e11f8674bda76bfe2bc93/
>
> This is a terrible idea.
>
> * There's no guarantee that the names will be unique.
You're right. But there are people relying on hashes being unique (apart from
really _searching_ for duplicates). If you need more security, append a
SHA-512 to the MD5 :-) [1] [2]
> * What happens when I "svn cp REPOS_URL/trunk
> REPOS_URL/branches/fubar"? Right, you mention that the client does
> the necessary magic (a *lot* of magic, so "only client changes
> required" is an undernstatement)
The tree is simply copied (as usual), with attributes pointing to the *old*
resource-forks. That's ok, since they didn't change.
Only if a client *changes* data, it has to create a new directory
in /resource-forks/.
> * What happens if I want to "svn mv REPOS_URL/macos-resource-forks
> REPOS_URL/macos-rsrc"? And what if I do this with a client that's
> not aware of the convention?
As you only change the *name* of something, the attributes describing where to
find the resource-forks stay the same.
If a client gets this via an update, changes something, and commits later, the
client notices that the path hashes to another value and creates a new
directory in /resource-forks, with copyfrom-path from the attribute.
So everything ok, everything versioned :-)
Regards,
Phil
[1]: see 4 in www.soe.ucsc.edu/~hongbo/publications/dde-msst04.pdf
[2]: see 3.2 in is.rice.edu/~pshuff/tamu/Hash%20Addressing%20-%20short.pdf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Ph. Marek wrote:
>Regarding the way resource forks and xattrs could be done in the repository
>I'd like to present an idea.
>
>First I assume the standard layout in the repository -
> /trunk
> /tags
> /branches
>
>Then there is some file, say
> /trunk/dir/file
>
>When this gets committed from a resource-fork-aware machine, the pathname in
>the repository gets hashed to a md5-sum:
> $ echo -n "/trunk/dir/file" | md5sum
> 71523811009e11f8674bda76bfe2bc93
>
>So a complete tree of forks/attributes can be stored in eg.
> /macos-resource-forks/71/52/3811009e11f8674bda76bfe2bc93/
>
>
This is a terrible idea.
* There's no guarantee that the names will be unique.
* What happens when I "svn cp REPOS_URL/trunk
REPOS_URL/branches/fubar"? Right, you mention that the client does
the necessary magic (a *lot* of magic, so "only client changes
required" is an undernstatement)
* What happens if I want to "svn mv REPOS_URL/macos-resource-forks
REPOS_URL/macos-rsrc"? And what if I do this with a client that's
not aware of the convention?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by "Ph. Marek" <ph...@bmlv.gv.at>.
Regarding the way resource forks and xattrs could be done in the repository
I'd like to present an idea.
First I assume the standard layout in the repository -
/trunk
/tags
/branches
Then there is some file, say
/trunk/dir/file
When this gets committed from a resource-fork-aware machine, the pathname in
the repository gets hashed to a md5-sum:
$ echo -n "/trunk/dir/file" | md5sum
71523811009e11f8674bda76bfe2bc93
So a complete tree of forks/attributes can be stored in eg.
/macos-resource-forks/71/52/3811009e11f8674bda76bfe2bc93/
And this path gets stored as an attribute to the file.
svn:mac-os-rf=/macos-resource-forks/71/52/3811009e11f8674bda76bfe2bc93/
Advantages:
- simple, clean model
- only client changes required
- attributes are still small entities
- we can store arbitrary large, versioned attribute trees -
svn:xattr=/xattr-resources/71/52/3811009e11f8674bda76bfe2bc93/
- on tag/branch creation, the attribute pointing to other data gets copied.
*But* as soon as another version is committed, the path in the repository
is different, so the hash is different, so a new rf directory gets started
(possibly a copy of the old).
- Non-resource-fork aware machines have only a vanishingly small penalty.
(Similar for xattr)
Comments??
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
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 <jp...@rowman.com>
>To: Vincent Lefevre <vi...@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
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by Vincent Lefevre <vi...@vinc17.org>.
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.
> >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 <jp...@rowman.com>
To: Vincent Lefevre <vi...@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).
[...]
--------------------
> $ 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?
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Vincent Lefevre wrote:
>On 2005-08-13 21:56:51 +0200, Branko Čibej wrote:
>
>
>>Eric Gorr wrote:
>>
>>
>>>Again, based on my understanding, support for extended attributes will
>>>be 'increasingly useful'. If some file system does not support such
>>>things, it really isn't a problem...subversion can just not look for
>>>such things on those file systems.
>>>
>>>
>>Yes, but it must represent them somehow in the working copy.
>>
>>
>
>Yes, as properties. Isn't this similar to symlink support?
>
>
No, symlinks are represented as files, not as properties.
>Is the size would be the only problem?
>
>
Size would be a serious problem. Of course, as somebody else mentioned,
xattrs aren't meant to be very large in the first place, so I can't see
how resource forks could be reasonably mapped to xattrs.
(With NTFS on Windows, you'd represent the resource fork as a real file
data stream. But that's neither here nor there.)
>Another solution would be to use filenames with '$' since they
>are forbidden in Subversion.
>
>
Huh? Since when?
$ 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
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork" support)
Posted by Vincent Lefevre <vi...@vinc17.org>.
On 2005-08-13 21:56:51 +0200, Branko Čibej wrote:
> Eric Gorr wrote:
> >Again, based on my understanding, support for extended attributes will
> >be 'increasingly useful'. If some file system does not support such
> >things, it really isn't a problem...subversion can just not look for
> >such things on those file systems.
>
> Yes, but it must represent them somehow in the working copy.
Yes, as properties. Isn't this similar to symlink support?
Is the size would be the only problem?
Another solution would be to use filenames with '$' since they
are forbidden in Subversion.
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Extended Attribute Support (was Re: Mac OS X "resource fork"
support)
Posted by Branko Čibej <br...@xbc.nu>.
Eric Gorr wrote:
> Branko Čibej wrote:
>
>> There are many filesystems that don't support extended attributes or
>> several data streams per file.
>
>
> Which is entirely irrelevent.
>
> Again, based on my understanding, support for extended attributes will
> be 'increasingly useful'. If some file system does not support such
> things, it really isn't a problem...subversion can just not look for
> such things on those file systems.
Yes, but it must represent them somehow in the working copy.
>> I don't think you can use properties for xattrs at the moment. The
>> practical constraints on property sizes are much stricter than on
>> file contents.
>
> I am curious, why are the constraints on property sizes 'practical'?
> Why would it not be reasonable to increase the allowed size?
It's due to how properties are stored in the repository, and how they're
transmitted to the client. Fixing the first part would require an
incompatible change to the FS schema, which implies svn-2.0. I'm not
sure the second part can eve be fixed within the WebDAV protocol.
> If it is not practical to use subversion file property features, then
> I suppose some other method would be needed to better support large
> sized file metadata.
>
> The point is, there is someone willing to volunteer to implement this
> extremely useful feature for those filesystems which do support
> extended attributes. It is the sole reason why using subversion is not
> practical at least in my specific case.
Well, we can always talk about specific design and implementation
issues. But this will touch almost every part of SVN, from the
filesystem to the working copy management code. I'm not saying "no" to
the idea, I'm just warning you that it's far from trivial.
Of course, if you can live with the current "practical" size limitations
(and I don't know what they are -- we'd have to try and see), then you
can certainly use properties to store extended attributes.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org