Johan Corveleyn wrote on Mon, Apr 25, 2011 at 01:08:24 +0200: > 2011/4/22 Branko Čibej <br...@e-reka.si>: > > Meh. For now, just hack a special case so that committing one half of a > > case-only rename will automagically commit the other half. Shouldn't be > > too hard to do, and it's almost impossible to do the wrong thing -- > > after all, you're constrained by a) staying in the same directory, and > > b) both halves of a rename resolving to the same on-disk file on a > > case-insensitive file system. > > Sounds like another option. A small change here and there to make > case-only renames work specifically (and not solve the more general > problem of fixing path-guessing via wc-db or truepaths). > > The fact of the matter is that, for sane setups/companies, > case-clashes are going to be really rare, *except when doing case-only > renames*. A repository holding 'Foo', 'FOo' and 'FOO' would be a > repository that's un-checkoutable on a case-insensitive filesystem
Un-checkoutable at depth >= svn_depth_files (assuming those 'foo' are files rather than directories). It makes perfect sense to me to have, say, both trunk/config.txt and trunk/CONFIG.txt, and tell people to do svn up --set-depth=exclude config.txt # remove the uppercase one && svn up --set-depth=infinity config.txt # pull the lowercase one , for example. It's a very cheap and effective way of ensuring at most one of the conflicting config.txt files is present. "Case-insensitive filesystems: it's not a bug, it's a feature." --- I'm not going to guess whether (and how many) people use Subversion this way; I'm only saying that the above workflow allows for coexisting case-clashing files and is supported by our released code. > anyway. So I'd expect companies that have to support case-insensitive > clients to keep real case-clashes out of their repository (or fix them > as soon as they are discovered). > > So maybe "case-only rename" (and perhaps "case-only replace" > (delete+add w/o history)) is the only use-case we need to go for. But > apart from commit, we should maybe also make "revert" possible, as > well as adding to and removing from changelists ... (hm, commit would > be the main thing I guess, revert can always be done in two steps > (revert the add, then the delete), changelists ... oh well). > > I'd love to hear some more input ... > > Cheers, > -- > Johan > > [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3865 ('svn' on > Windows cannot address scheduled-for-delete file, if another file > differing only in case is present on disk)