[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: The Data Sanitization Plan

From: William Uther <will+_at_cs.cmu.edu>
Date: 2002-06-25 22:33:13 CEST

On 25/6/02 3:52 PM, "Ben Collins-Sussman" <sussman@collab.net> wrote:

>
> Karl and I are talking about how to tackle issues #494 and #667
> together as a unit. After reading and discussing, here's our Plan.
>
> Essentially, we are imposing an Official set of burdens upon all svn
> client applications, (i.e. any users of the libsvn_* libraries):
>
> 1. all paths passed to libsvn_* are assumed to be
>
> - using '/' separators
> - using canonicalized case
> - in UTF-8

I don't think this entirely solves issue 667.

I just added the following to that issue:

Path canonicalization handles most, but not all, of this issue.

 - 'svn mv myFile myfile' still needs to be able to rename a file to a new
case. Canonicalizing this into a nop isn't the answer.
 - Canonicalization only really helps when the problem comes from the
command line. If there is a conflict when files are checked out/updated,
there needs to be a reasonable error message. e.g. if the repos contains
both 'myfile' and 'myFile' in a directory then I believe that'll cause
issues on Mac OS X when you try and check out.

  The solution should probably generalize to an error when trying to check
out any file that cannot be represented on the current system because of
either an illegal character in the file name or because two different
filenames alias to the same file on the current filesystem (because of
case). (I agree svn doesn't neccessarily have to work with these files, but
it should at least get the error message right.)

Later,

\x/ill :-}

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 25 22:34:07 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.