Hello all,
As in my conversation with Flex, I use the following abbreviations:
case sensitive = CS
non case sensitive = NCS
Flex wrote:
> I'm posting a conversation with A.T.Hofkamp about the problem and my
> suggestion on it since the discussion touches that topic too.
I did a bit of thinking while doing the dishes this weekend, and came to the
conclusion that a project with mixed CS and NCS machines needs to have a
policy for filenames, ie some set of conventions how to name each source file.
svn should provide support for such a policy imho, in some form.
What form exactly is to be decided, see below for some initial thoughts.
(no doubt there are some gaping holes somewhere :-) ).
As to the question where such a policy should be enforced, there are two
options as far as I can see:
1. centrally at the svn server
2. decentrally at the svn clients
While 1 is very attractive for having repository-wide consistency for such a
policy, I think it cannot be done (easily, at least):
a. CS clients will not be able to relate myfile with MYFILE with all the
problems now experienced at NCS machines along with it (maybe this also holds
for NCS clients, I haven't considered that).
b. In addition, URI's are by default case-sensitive. In my view that means
that an URI given to the svn server for an added file should be stored and
used for all clients, the server cannot change the URI to enforce some name
policy.
c. Last but not least, a repository may contain multiple project, and each
project may have a different policy for file-names. I don't yet see how to
implement different naming policies for different parts of the repository.
With 1 out the window (as far as I have thought things through above), the
only feasible solution seems 2, have each client enforce the naming policy.
In other words, each client normalizes its filenames locally to the policy
before sending them to the svn server.
If different clients use different policies, you get chaos, so either the
normalization should be such that policy conflicts are caught locally, or
clients use the central server for normalizing (eg an svn client asks the
server 'i have file "myfile", what is the normalized filename?'). The latter
solution has as disadvantage that a server network connection is necessary,
something which may be against the svn design principles (no doubt somebody at
the list will be able to tell this).
The most feasible approach thus seems to be decentralized filename
normalization, with catching clashing policies, in order to avoid chaos.
(ie I am not considering asking the central server for normalized filenames).
When locally enforcing a naming policy, the question then is which filenames
can be trusted (w.r.t. case) and which not.
As far as I can see, there are 3 kinds of filenames:
1. filenames from the repository
2. filenames from the local (NCS) file system
3. filenames entered at the command-line / through the GUI (ie "myfile" in
"svn add myfile").
I would suggest that 1 can be trusted, 2 cannot be trusted (at least for NCS
machines), and 3 is tricky.
If 3 comes from the command-line svn, I think its case can be trusted, a user
will typically type the correct case. On the other hand, if a (GUI) program is
used, that program will typically use filenames from the file system, which
cannot be trusted :-)
If 3 is trusted, then the only problem is to map names from 2 to names from 1
or 3, which can be done in the way Flex suggested in his answer to my email
(posted at this list 19/08/05 19:10).
If 3 cannot be trusted, then an svn client needs its own subroutine to
normalize files (otherwise there is no trusted source for new files).
This can take the form of a regular expression match/replace algorithm, for
example a configuration file like
gnumakefile = GNUmakefile
*.c = *.c
(I assume the left pattern is NCS, while the right is CS).
This can be expanded with additional syntax to normalize the expansion of the
* at the right to lowercase/uppercase/initialcaps.
With such a normalization, svn can compute the normalized filename for any
name. names from the file system can be normalized before sending them to the
repository for instance.
Policy clashes can be detected by normalizing the names from the repository,
and checking that they haven't changed in case.
I haven't considered what should happen when a clash is detected.
comments?
Albert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 18:38:53 2005