The discussion gets more and more interesting :)
Monday, August 22, 2005, 11:09:02 PM, you wrote:
> You have said a comparison should happen, very well, but where? The
> server cannot modify a transaction so all that is left is the clients.
Yesterday I think, Albert Hofkamp even pointed to a date/time.
Searching...
To not paste the whole discussion, the ida is a commandline switch to
be added so the client can "notify" it wants case insensitive
compares. All the current clients/implementations/whatever will run as
before, only updated ones can make use of it...
====================================================================
I think in a system that is supposed to handle both CS & NCS systems,
the CS should have priority.
Several cases:
1. I create a new file from the NCS system:
svn up \\path\to\file.C -NCS
it has 2 ways to be stored - either all lowercase (file.c) or the case
it is at now (file.C). I prefer the first one but it doesn't really
matter. Let's take the first case and it gets stored as file.c in the
repository.
If I put it again with changed case from the NCS system with -NCS option:
svn up \\path\to\FILE.C -NCS
The idea is svn to not assume this is a different file, but to take
the stored one (file.c) and update it, keeping the case the same.
Since NCS system does not care about the file case, the case in the
repository takes priority and the file will be checked out how it was
written in no matter what case u used to update it.
2. I create a new file fron CS system
svn up \\path\to\FiLe.C
Alright, then a NCS client gets FiLe.C when checking out and no matter
if it tries to up it as a file.c, the case of the repository is
considered leading and the file stays as FiLe.C
Again, it's a matter of one compare somewhere or one compare function
change.
=====================================================================
> How do you propose to handle all the possible clients and force them to
> be consistent based on the servers abilities?
This is just a new option like every one added in svn over time. Those
that got updated use it, those which aren't - just work the "old" way
so nobody's work gots broken. Backward compatibility :)
> It wouldn't be difficult to write a rogue client to break the
> all-lower-case assumption and possibly corrupt the repository.
With the case insensitive flag I don't see how can it be broken. The
CS should always take a priority
> AFAIK this is why the rejection of the transaction on the server is the
> best solution so far.
:)
> How can it not be anybodies fault? Someone/thing must have changed the
> case of the file in the process of modifying it. As Ralph Wiggum would
> say "That is unpossible!" ;)
It's not a fault, it's just by design. We are talking about NCS file
system here.
> Non-deterministic behaviour is a broad definition of an error for highly
> reliable systems.
Agreed, on the term, however if you have 2 choices and nobody
restricts you in making any of them, you are not the bad guy then for
selecting which one you get in mind firts.
And it's not about automatic decision at all. I for example like my
files to be "Sentence-cased" - i.e. File.c. My colleague likes them
all lowercased, in the firmware they have always turned on the caps,
with the idea that there are no small letters in the world and they
have FILE.ASM. I may change some file, if I don't like it's case, they
may too... in NCS system there's no difference.
> That is untrue. Many SVN developers and users use Windows and Macs.
> Also note that it _is_ possible to use a case insensitive file system in
> Unix or Mac (FAT). It just isn't the general case.
Yeah I kno, speaking in general
> Could the same also be said about Windows? Surely someone must have
> written a case sensitive file system for Windows.
Yep... paragon mount everything or similar can access linux file
systems. And about this one... if you ask me and probably all windows
users - case sensitive file system is just another level of complexity
and error prone since to have file.C and file.c at the same place with
the same name looks odd and useless to me, I better stick to the idea
tha whatever I write - FilE.C, file.c, FILE.C... I'll get to it.
> Invitations like above are often the result of these conversations. But
> for whatever reason, no one seems to have the skills or ability to
> architect and implement a clear and consistent solution. That is -- not
> just a cheap hack to put in a client switch.
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 22 22:35:22 2005