On Thursday 20 July 2006 18:04 Malcolm Rowe wrote:
> 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
Thank you.
> , but don't see how it can be
> introduced before a 2.0 release
Why? Please read the points below.
> (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).
There has to be a property "svn:filename-encoded" set to "*", similar to the
way svn:executable works, to enable filename translation.
> 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.
From the patch:
+ if (decoded == 0)
+ return svn_error_createf
+ (SVN_ERR_FS_PATH_SYNTAX, NULL,
+ _("Path '%s' needs not be decoded!"),
+ svn_path_local_style(path, pool));
> 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.
> 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.
No. Everything below the fs-layer doesn't change. Only clients need to
know "if the property X is set, I have to translate the filename".
If the filename needed no translation, it's an error.
Thank you for your feedback. I hope I addressed all your points - if there are
any other problems I may have overlooked, please don't hesitate to tell me.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
---------------------------------------------------------------------
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:29:52 2006