Hello,
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.
The problem I see here is you can do case folding as much as you like, but at
some point you have to commit new files to the server with the correct
filename (case-wise). That means that somewhere you have to decide whether to
submit "file.c" or "file.C".
Other svn clients get that filename and use eg the case of the 'c' for
deciding whether you gave them a program written in C or a program written in
c++ . That makes a huge difference in how to process the file.
What I don't understand is how you enforce eg that C program files end with .c
and c++ program files end with .C at the repository
(let's ignore the possibility of having file.c and file.C at the same time in
the same directory for the time being).
> 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.
I don't think any one would want to have different policies in different
directories, so they are mostly the same everywhere but I can agree with you
(I'd just replicate the same policy to every directory).
>
> 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.
If I cannot rely on the case of a filename, how do I state whether a file is C
program or a c++ program?
Note that having different names for the same thing at different platforms is
bad if only because scripting/tooling typically breaks when you change names.
One shouldn't have to supply different versions of the same scripts because of
svn, would they?
> 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.
Agreed.
>
> 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.
so wouldn't checking when new filenames are introduced be enough here?
what is the added value of the tag?
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 23 13:51:23 2005