On Dec 22, 2004, at 7:41 PM, Philip Martin wrote:
> Scott Palmer <scott@digital-rapids.com> writes:
>
>> you can't _directly_ rename "Abc" to "abc".
>> ...
>> Surely THAT can be easily fixed?
>
> If you are talking about a wc-to-wc copy then no, it's hard. At
> present mv is implemented as copy+delete. That means that until the
> delete is committed the working copy has to maintain files associated
> with both "Abc" and "abc".
>
> $ ls wc
> foo
> $ svn mv wc/foo wc/FOO
> A wc/FOO
> D wc/foo
>
Thanks for the explanation Philip. It helps.
I am left with some basic questions though. If a file in the WC is
scheduled for deletion why does the main WC file have to remain? All
of the info involving the scheduled delete is contained exclusively in
the .svn folder, where some convention can be used to differentiate
files that only differ by case. I'm assuming now that it is this issue
of preserving case sensitive paths within the .svn folder that is the
big problem here.
There are obvious solutions though, since a FSFS repository on Windows
can hold the files in the first place. Of course .svn folders likely
can't use the same method to store the data need there. One solution
is to prefix all uppercase letters with '_' and actual '_' would be
represented by two '_' in a row, within the .svn folder. The major
flaw there is that huge names could exceed the platforms limit for
pathnames where normally they would not, but that sort of platform
difference can't be accounted for anyway.
Question 2: With respect to the repository, since the commit will be
atomic and nothing happens unless everything happens successfully, why
can't the delete happen BEFORE the add at a finer level?
_brane..._ wrote:
> Gili wrote:
>
>> On Wed, 22 Dec 2004 21:53:39 +0100, _brane..._ wrote:
>>
>> >Hear me: regardless of the encoding used, case folding is
>> >locale-dependent. It doesn't matter a bit whether the OS uses
>> Unicode or
>> >not.
>>
>> How so? I fail to see how case-folding is locale-dependant under
>> unicode.
>
> Because different languages don't always agree about a) which letters
> are uppercase and which are lowercase, and b) how to convert from one
> to the other.
But this issue is already solved on the OS hosting the file system. It
is already doing SOMETHING to determine that two, different in case
only, paths refer to the same file. Is there a simple way to get the
OS to do the hard stuff for you? After all it is the OS's
interpretation that ultimately will matter.
A crude way to deal with it, might be to simply open each of two
possible paths with exclusive access. If you succeed they can't
possibly be the same file... though if you fail it does not guarantee
that they are. Yes, it would be best to come up with something better
than that.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 23 15:58:02 2004