> Now, yes, it would be nice to work around this but it is a
> PITA and will still end up causing Windows users problems
> because the moment they manipulate the file/directory with
> traditional "windows" tools the dots at the end of the file
> will disappear.
>
> Please don't blame Subversion for something that is OS specific.
I'm not blaming Subversion for renaming the file. I'm blaming
it for claiming that the file is not there, when it really is
(although under a different name).
IOW, I complain that Tortoise marks the entire tree as modified
(red signal), when there really isn't any modification at all
in the tree. This is not something the system does; this is
subversion's doing.
One solution would be to really create the file with a "proper"
name, through a 1:1 mapping between repository names and disk
names (using the very same name if at all possible). That would
also apply to files containing, say, ":" - e.g. by mapping
U+003A to U+F03A, which incidentally would be the same mapping
that the POSIX subsystem of Windows uses.
Another solution would be to recognize that the renaming has
occurred, and represent that in the state of the repository.
Instead of saying that the file is "missing", report (to the
client application) that the file has an unsupported name.
Then infer that files with unsupported names cannot be added,
removed, or modified.
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 12:22:23 2006