On Sat, Aug 4, 2012 at 7:23 AM, Stefan Sperling <s...@apache.org> wrote: > On Thu, Jul 07, 2011 at 04:21:33PM +0200, Andreas Krey wrote: >> On Thu, 07 Jul 2011 11:14:13 +0000, Vitus Piroutz wrote: >> ... >> > PS.: i think i have to try Git next. >> >> As of git 1.7.2 you won't get lucky. From a software point of view MacOS >> behaves seriously annoying here. (For git it even has consequences for >> the way the checksums are computed.) A stat on the composed file name >> still works (arguably correctly) even though the decomposed name shows >> up in directory listings and thus in 'git status' as untracked file. > > It's been almost a year, and interestingly, git is now starting to tackle > this problem: > http://repo.or.cz/w/git.git/commit/76759c7dff53e8c84e975b88cb8245587c14c7ba > > The commit message makes no mention of potential compatibility issues > with existing repositories. I wonder how they plan to deal with paths > that are stored in decomposed form in existing repositories. Maybe this > is not an issue for git for some reason? Maybe they'll let users run into > issues and then fix them? Maybe their dynamic rename detection makes this > less of an issue than it is for Subversion?
Maybe most users simply work in 7-bit ASCII character sets and avoid whitespace, punctuation, and Roman-characters as s matter of common practice for software stability? I, for one, have encountered disasters when "pre-commit" and "post-commit" scripting was not written to handle filenames with punctuation. And even on the fileysteem level, I've encountered situations where Windows users with CIFS access to a Subversion repository could make and record files with umlauts and other Unicode supported international characters, but the underlying fileystem could not even access or report the filenames correctly with the published NFS access to the same material. That one.... took rebuilding the backend storage systems to fix. and simply avoid the problem altogether? > > I've Cc'd Thorsten in case he wants to share his thoughts on this > (see http://subversion.tigris.org/issues/show_bug.cgi?id=2464 > for context).
