On Thu, Jul 20, 2006 at 04:39:10PM +0200, Philipp Marek wrote:
> I'd like to ask you to vote for/against comitting *such a* patch; if the
> encoding format is defined it's much easier for all people to produce
> complying clients.
>
I understand the need for such a feature, but don't see how it can be
introduced before a 2.0 release (at which point, there's definitely a
cleaner way to do it). A few immediate things come to mind with the
current design, though there are probably more:
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).
2. With the currently-proposed design, you can have two files with the
same decoded name, for example, a file called 'foo' and another called
'\x66oo', the latter with the encoded property set. This is fixable to
some extent by making such instances errors, in the same fashion as a
non-minimal UTF-8 encoding, but the main problem in #1 still exists.
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...).
4. If I save a dump out and load it into an earlier version of Subversion,
my load can fail as a result of at least #1 above (there may be other
problems too). This might be solvable under the 'if you use new features
they might not be backward-compatible' mantra, but it would be a major
stretch to apply this to the dumpfile format, which is supposed to be
backward-compatible by default.
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 18:07:11 2006