The locale _must_ be set somewhere in order for this to work. I'd
suggest svn:resolve-case have two lines,
the second being as you have noted, but the first being a
"locale:[TheLocale]" part. If the server is to reject
commits, it must know what to reject, mustnt it?
furthermore, if adding this property, it doesnt seem all so sensible to
have such a binary reject/accept action.
If the locale is set, if specific rules are set up as to what filenames
to treat as being "the same file", why not
simply have the client/server treat them as "the same file" if the
properties are set as such? Yes, the complexity
issue, and a simple binary reject/accept does seem an appropriate
starting point, but that complexity really
should be there.
There should be no loss of data because errors would occur at the time
of "svn add" if the client knows about
the locale setting, or conflicts would be raised at the time of commit
if-and-only-if the client attempts to send
two files with the same name.
(perhaps, however, this conflict should be raised if the client detects
two files with "the same name" even if
the client has not specifically said to add both of them. This would
require a --ignore-unversioned-resolve-case,
or something better named than that)
Joshua Varner wrote:
>[DESIGN] svn:resolve-case
>
>I would like to propose a new property and some concomitant behavior
>for subversion. This in response to the "CaSe insensetive OS not handled well"
>thread recently. If this covers the main concerns addressed, I'll forward
>it to dev and see what the response is there. I may not have time to implement
>this immediately, but with a design locked down anyone can make the
>necessary changes. The current major obstacle is lack of a design for dev
>review and approval.
>
>I'm, also, not attached to the property names, but they seem reasonable.
>
>Josh
>
>ABSTRACT
>
>svn:resolve-case would be a directory property that, when set, would
>indicate to clients on how to resolve naming conflicts with regard to
>case.
>
>MOTIVATION
>
>Subversion is intended to operate on a variety of platforms of varying
>capabilities and to allow projects to operate as smoothly as possible
>on all platforms. One of the capabilities that varies is a file
>system's handling of case differences in filenames. A number of
>systems are case-insensitive, and while it is possible to work around
>this "limitation/capability" (not passing judgment) manually, it
>makes sense to provide assistance in this regard. This difference is
>comparable to the handling of line ending differences between
>platforms.
>
>ASSUMPTIONS
>
>1) Case folding varies by locale, thus two clients may handle case
> folding differently, and a server and client may handle case
> folding differently. This situation is analogous to line endings in
> that any conversions necessary for line endings are made at the
> client. So, all case-folding should occur at the client end; the
> server's internal representation is case sensitive so a commit that
> is incorrect in one locale or on one client machine will still be
> representable in the server so that error recovery can be handled
> through URLs.
>
>2.) Name clashed exist at the directory level, i.e. a file cannot
> have a conflict with its own name (they are identical). So a
> property indicating how to handle name conflict resolutions should
> exist at the directory level.
>
>OBJECTIONS
>
>1.) A client could create two files with conflicting names either
> maliciously or by accident.
>
> Yes, this can occur. But then again this can occur with eol
> settings, too. A client can inadvertently do eol processing on a
> binary file, or submit a file without first converting to the
> proper style of line endings. The real question is whether or not
> an error of this type is recoverable. Since the repository format
> is case sensitive it will not lose information, and URL
> commands can be used to resolve any errors.
>
>2.) Different locales will handle case folding differently and with
> this handled at the client end, this could cause
> difficulties within a project run in different locales.
>
> Yes, this can also occur. By providing the ability to manually
> specify the case stored in the repository for a given file,
> exceptional conflicts may be resolved by hand when necessary;
> common uses cases would still be handled programmatically.
>
>3.) What if people disagree on the "proper" casing of a filename?
>
> If they can't agree on this, then they need more help than Subversion
> can supply.
>
>PROPERTIES
>
>svn:resolve-case
> If svn:resolve-case is set on a directory then all filenames passed
> between the file system and the svn server should be munged into a
> "resolved" form. This property make take several values:
>
> force-lower - All filenames are stored as lowercase in the
> repository
> initial - All filenames are stored in the case in which they
> existed on addition to the repository
> . . . (others Initial Capital, Upper, needs to be a short list)
> empty - Check for svn:case-folded
>
>svn:case-folded
> File property that, when set and the file exists in a directory with
> svn:resolve-case set, uses its value to override the heuristic
> set by svn:resolve-case.
>
>ERROR RECOVERY
> When a directory is checked out - the client should check if the names
> violate the svn:resolve-case property, and if so throw an error indicating
> to the users that a conflict exists. Case sensitive file systems may be
> to finish downloading the directory, and then fix the problem in their
> working copy, but this adds extra complexity and it would be simpler to
> just abort and make the user resolve the problem with URLs. Additionally,
> adds and moves should check for name conflicts when svn:resolve-case
> is set.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 23 03:22:13 2005