Re: UNS: SVN not usable on a Mac (#2464)
On Thu, Jul 07, 2011 at 04:21:33PM +0200, Andreas Krey wrote: > On Thu, 07 Jul 2011 11:14:13 +, 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? 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).
Re: UNS: SVN not usable on a Mac (#2464)
On Sat, Aug 4, 2012 at 7:23 AM, Stefan Sperling wrote: > On Thu, Jul 07, 2011 at 04:21:33PM +0200, Andreas Krey wrote: >> On Thu, 07 Jul 2011 11:14:13 +, 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).
Re: UNS: Re: UNS: SVN not usable on a Mac (#2464)
On Sat, 04 Aug 2012 14:52:07 +, Nico Kadel-Garcia wrote: ... > 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? Fun can be had with special characters on almost every platfrom. And moving outside of ASCII also has surprises with LANG=C, unfortunately. (In my understanding LANG tells what console I/O should be, not how file names are interpreted.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: UNS: Re: UNS: SVN not usable on a Mac (#2464)
On Sat, Aug 04, 2012 at 09:00:49PM +0200, Andreas Krey wrote: > And moving outside of ASCII also has surprises with LANG=C, unfortunately. That is the way it is supposed to be according to POSIX. The "C" environment is ASCII. Newer C standard versions apparently allow for unicode in C symbol names but I'm not sure if any system has already implemented this, and I doubt it affects locales (haven't checked though). > (In my understanding LANG tells what console I/O should be, not how file > names are interpreted.) To my knowledge there is nothing in POSIX that says how filenames should be interpreted. They're always considered a string of bytes.
