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

Re: [PATCH] Re: Issue 1954

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-07-20 20:56:02 CEST

On Thu, Jul 20, 2006 at 08:29:07PM +0200, Philipp Marek wrote:
> > 1. What happens if you have two files with the same encoded name? (one
> > encoded, one not?). For example, two files called 'foo\x09bar' and
> > 'foo^Ibar' (where ^I represents a real TAB character).
> There has to be a property "svn:filename-encoded" set to "*", similar to the
> way svn:executable works, to enable filename translation.
>

Yes, but I assumed that this would be applied automatically where
necessary? So if you add a file called 'foo^Ibar', it would actually
create a file in the filesystem called 'foo\x09bar' with property
filename-encoded set. If not, assume that the user has done whatever
magic is necessary to add this file.

What happens when the user now adds a file that's really called
'foo\x09bar'? (note that you aren't allowed to require that '\' be
escaped, since that wouldn't be compatible with existing repositories).

> > 3. The filesystem code now needs to know about properties in order to work
> > out to what a filename refers. That seems wrong, since you can't carry
> > out operations on the pathname alone (for example, how do you interpret
> > what the [necessarily encoded] copyfrom path of a file refers to?
> > You'd need to find the copyfrom'd file before you could check what the
> > property value was, which you need to do before you know what the name
> > of the file is...).
> No. The working copy layer, which gets the properties on update, knows if the
> property is set, and can do the translation or not.
>

Okay, so anyone accessing the filesystem through the repos or fs layers
sees the encoded filename. That's potentially confusing ('ls' will
return different filenames to 'svn ls', all the URL-using operations
need to understand how to encode the filename), but I guess it does fix
several of the problems I mentioned.

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 20 20:56:47 2006

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.