On 2/6/06, von Löwis Martin <Martin.vonLoewis@hpi.uni-potsdam.de> wrote:
> > > So Subversion *could* find out easily and efficiently that
> > > the file it created is indeed still there.
> >
> > And what should Subversion then do? The file is not there,
> > is that due to someone deleting it just as it was placed
> > there (race condition) or the filesystem being annoying or what?
>
> Well, subversion would find out that the file *is* there. It
> would either open it, or invoke GetFileAttributes. That call
> would succeed, so it knows for sure that the file is there.
>
> > BTW - I have added some Win32 environment specific trouble
> > cases to my test case repository. Check out:
> >
> > http://svn.sinz.com/svn/example/trunk/tests/Win32-Tests/
> >
> > At what point does a tool such as Subversion just throw up
> > its hands and say "If it hurts, don't do that!" for those who
> > are cross-platform users of a shared repository. Otherwise
> > we could get into all sorts of problems when we start
> > filtering to the lowest common denominator.
>
> Precisely my point. Restricting yourself to the lowest common
> denominator is not really helpful, so Subversion does need
> to deal with "unsupported" cases somehow.
Deal with it how? If there is a file that fails on Windows, what
should it do? Somehow rename that file? What about the case of
two files: "More" and "More..." which end up being collapsed onto
each other on the Windows platform? (Or "more" and "More")
The answer really is "Don't Do That" to your repository if you
use that platform. Otherwise we get limits that end up not supporting
Unicode filenames or high-bit filenames or longer than 8.3 or...
Subversion does its best to not be wrong but if the platform
fundamentally can not support some name or pattern, then
don't use it.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 6 16:03:17 2006