> I'm afraid you are mistaken. One of the ways that Subversion
> checks to see if your working copy is up to date is to
> compare the files that exist on the disk with the files that
> should be there (as reflected in the .svn/entries file).
> NTFS will not correctly return the files which were
> automatically renamed (AFAIK whether opendir() or stat() were used).
You know wrong. A directory listing will not return the files,
but stat will report them. Watch this (it's Python, but it directly
maps msvcrt):
py> os.chdir("tmp")
py> f=open("Foo...","w")
py> f.write("Test")
py> f.close()
py> os.listdir(".")
['Foo']
py> os.stat("Foo...")
(33206, 0L, 2, 1, 0, 0, 4L, 1139240730, 1139240730, 1139240724)
py> open("Foo...").read()
'Test'
> If you have a working copy in this state, it should show you
> an unknown file without the trailing dots and a missing file
> with the trailing dots.
That's what happens. I disagree this is what should happen.
> It isn't Subversion's fault and
> without negatively affecting everyone's performance who
> didn't make that mistake, I really don't see what Subversion
> can do to work around the limitation.
It isn't subversion's fault that the file is renamed, right.
However, it *is* subversion's fault that it displays the file
as missing (it could find out efficiently that it is not
missing), and it is subversion's fault that it doesn't offer
a work-around other than "don't do that, then". Offering
svn:filename.win32 would be such a work-around.
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 6 18:29:57 2006