[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
Received on Tue Aug 23 00:13:23 2005