> -----Original Message-----
> From: Branko ÄŒibej [mailto:brane_at_wandisco.com]
> Sent: dinsdag 23 juli 2013 14:39
> To: users_at_subversion.apache.org
> Subject: Re: Files ending with . (dot) on Windows
>
> On 13.07.2013 18:35, Bert Huijben wrote:
> >
> >> -----Original Message-----
> >> From: Daniel Shahaf [mailto:danielsh_at_elego.de]
> >> Sent: vrijdag 12 juli 2013 18:20
> >> To: Staton, Bradley D.
> >> Cc: users_at_subversion.apache.org
> >> Subject: Re: Files ending with . (dot) on Windows
> >>
> >> Staton, Bradley D. wrote on Thu, Jul 11, 2013 at 15:31:07 -0400:
> >>> C:\tmp\playrepo\trunk>svn status
> >>> ? src\main\resources\fileEndingWithDot
> >>> ! src\main\resources\fileEndingWithDot.
> >> It'll be easiest to fix this after (or along with) the Unicode NFC/NFD
> >> issues --- the fix to that issue will install the infrastructure
> >> required to fix this issue.
> > I don't think this will be easy to fix as a final '.' is in many cases
> > silently removed on Windows, for backwards compatibility with the old 8.3
> > names on FAT.
> > (Just check the apr sourcecode for normalizing paths to see the very ugly
> > details)
> >
> > So, yes it will be in the same category as the NFC/NFD problems... But while
> > for the NFC/NFD problems MAC/OS users might want to take a 20-30%
> > performance hit on 'svn status', I don't expect the Windows users to be as
> > willing for this very specific problem.
>
> Where do you expect the performance hit to come from? I can't think of a
> good reason for it.
The simple assumption through 'libsvn_wc' and 'libsvn_client' that the file on disk matches the name stored in each and every hashtable. And that every 'switched path' calculation no longer works when you change that assumption
And the fact that once you remove this assumption that was valid since the very early days, you have to check for possible collisions everywhere. So you can't just fix it with a better hashtable.
And the 'simple fix' of applying a collation on the database layer, is never going to handle all the crazy rules about paths that exist on Windows in the different layers. (NTFS doesn't have many rules; the GUI explorer has other rules. Cmd.exe different rules)
I'd like to see you prove otherwise, but I don't expect to see 'a simple solution' using one additional column in wc.db any time soon.
Bert
Received on 2013-07-23 15:31:59 CEST