[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

regarding issue 667: data loss??

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-06-01 14:34:36 CEST

I'm confused about the scope of this issue. It was originally about
little annoyances here and there in dealing with case-insenstive
filesystems (OSX, NTFS). But a month ago, SteveKing added a description
that makes the issue sound much more serious, followed by a even more
recent comment from Michael Bevin. Both of these people are complaining
of data loss, which means P1 in my mind. I'd like to bring this problem
into the spotlight for a moment.

SteveKing's description says:

"It seems that this issue has become a serious one for many windows
users. I'm getting reproducable reports from TSVN users who lost their
data because of this. There are some older text editors on windows who
automatically change the filename to all uppercase on saving.
example:
working copy with some files in it. One of those files is testfile.txt.
Edit testfile.txt and save it with an old editor
testfile.txt is now TESTFILE.TXT in the working copy.
do an 'svn up'
> Restored 'testfile.txt"
and the modifications on that file are gone! They got reverted during the
update."

Can someone explain to me what's happening in this example? I'm trying
to guess at what the editor and Subversion are doing.

When the editor saves the file as TESTFILE.TXT, that means that
testfile.txt is no longer present, right? Because it's impossible for
those two files to exist simultaneously in the same directory, right?
Then I'm guessing that 'svn up' does a case-sensitive comparison of
TESTFILE.TXT against the entries-file name of testfile.txt, decides the
entry is "missing", so it restores it from the text-base. But in the
process of copying .svn/text-base/testfile.txt to ./testfile.txt, it
overwrites the modified TESTFILE.TXT...again, due to the
case-insensitive filesystem.

Is this an accurate analysis?

If so, here are solutions that I do *not* think are legitimate:

* make the repository "sometimes case insensitive". No way, no how.
The repository filesystem is case-sensitive, period. That's the
design. It's the svn client's job to deal with case-sensitivity issues.

* tell every win32 user, "use a better editor!"

In my ignorance of win32-ness, my instinctive proposal is to somehow
teach libsvn_wc to be aware of its underlying filesystem. If it's a
case-insensitive one, then it should be doing case-insensitive filename
comparisons. If it's a case-sensitive filesystem, then do
case-sensitive comparisons. But perhaps we've gone down this road
before. Folks, please speak up about this.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 1 14:35:00 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.