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

Re: Issue 1954

From: Philipp Marek <philipp_at_marek.priv.at>
Date: 2006-07-16 11:21:54 CEST

On Friday 14 July 2006 18:13 C. Michael Pilato wrote:
> Philipp Marek wrote:
> > And in subversion/libsvn_fs/fs-loader.c I see this function:
> > svn_error_t *
> > svn_fs_make_file(svn_fs_root_t *root, const char *path, apr_pool_t
> > *pool) {
> > SVN_ERR(svn_path_check_valid(path, pool));
> > return root->vtable->make_file(root, path, pool);
> > }
> > which makes me believe that this should happen for the repository, too.
> Good lord. I must have been sleeping when somebody snuck that rubbish into
> the codebase. [Eyes kfogel suspiciously.] Sorry for inadvertantly
> misleading you, Philipp. FWIW, I strongly disagree with this change to
> libsvn_fs. If someone wanted to protect the repository, they should have
> done so by introducing a wrapper in libsvn_repos.
But the question would remain! It's not possible to allow *every* character in
filenames, else eg. the dump format may be damaged (by \n in filenames).
Similar a \r may cause problems on win32, and so on ....

Is there a list of invalid characters *for the repository*, and/or do we
simply define it as the current allowed list?

I'd vote for not changing the behaviour (always a good bet :-), and simply
defining an extension, eg. my idea 2 (encoding like "tab\\x09name", flag

Is there any other/better kind to handle that?



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 Sun Jul 16 11:22:23 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.