On 2/7/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> Justin Erenkrantz wrote:
> >
> > The key is to not let those files in the repos at all -
>
> For a particular project, the administrator might want to ensure that some or
> all files are named so as to be accessible on every possible platform; that's
> fine. However, most repository administrators, and certainly Subversion
Right - which is why a custom pre-commit hook makes sense for those situations.
(I wasn't advocating always creating that pre-commit hook.)
> It may be true that there is no accurate way to determine what FS "you are on"
> (more precisely, on which a particular file is stored). It is wrong to imply
> that the WC can't cope. There are all sorts of ideas for what the WC could do.
No. You have no way to know how the underlying file system will
handle with these conflicting/incompatible names. Mac OS X will just
overwrite the files. Windows just trims off the dots silently.
> Here's my addition to these ideas: The WC has a concept of a "missing" file
> that is used when the user doesn't have read access to a particular file in the
> repository. The WC knows that such a file exists in the repos but is not
> present in the WC. Leaving an incompatibly-named file out of the WC and using
> this "missing" status seems like a possible part of a solution.
If you could tell that it was missing or written incorrectly, perhaps.
But, I don't think you can even know that the file wasn't handled
correctly. On Mac OS X hsfs, the stat() for the case-insensitive
names will success return for all variations. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 7 23:53:18 2006