[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.


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.