[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: Ph. Marek <philipp.marek_at_bmlv.gv.at>
Date: 2005-08-18 08:28:28 CEST

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
Received on Thu Aug 18 08:29:25 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.