On Mon, 25 Apr 2005, Charles Bailey wrote:
> On 4/25/05, Hinnerk Haardt <haardt@randnotizen.de> wrote:
> > this:
> >
> > > $ svn ci
> > > svn: Commit failed (details follow):
> > > $
> >
> > is caused by "^M":
> >
> > > $ ls -la
> > > drwxr-xr-x 6 haardt haardt 204 12 Feb 2004 Contents
> > > -rw-r--r-- 1 haardt haardt 0 11 Feb 2004 Icon?
> > > $ ls <TAB> <TAB>
> > > Contents Icon^M
> >
> > there's an newline in the filename and there are quite a few more of
> > them hidden in Mac OS X applications. They can be found using something
> > like "find . ! -name "*[a-z|A-Z|0-9|:|$|}|_|+|-|~|)|\!|\?|\]|\#|\.]"".
> > They can not be seen in tho output of "find" but will show up on Bash
> > autocompletion (hence the "<TAB> <TAB>" above).
>
> I'm not deeply familiar with svn internals, but this seems to arise
> because path names are represented as XML in svn's admin files, and
> control characters generate problems. While my reading of the XML 1.0
> spec is that CR is strictly legal in CDATA, I'm not sure the parser
> can distinguish between a CR that's part of the data and a CR that's
> just whitespace (nor am I entirely sure that it should interpret an
> unescaped CR as data; that's for better XML lawyers to decide).
>
CR is valid in XML and the parser should report it. We decided to disallow
all control characters for various reasons.
> For now, my experience has been that it's best to avoid filenames with
> control chars in them. That does cause some problems on OS X, but I
> don't know of a good work-around offhand.
Does OS X apps make legitimate use of CR in file names?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Apr 25 15:18:18 2005