On Mon, Apr 25, 2011 at 4:56 PM, Daniel Shahaf <d...@daniel.shahaf.name> wrote: > 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.
Ok, disregarding for a second that I think this is pretty contrived :-), I think this works perfectly well right now AFAICS. Because you first (have to) exclude/remove the one that's currently on-disk, there is no longer any truepath conversion going on after that. So the user is then free to choose whichever of the case-clashing files to get from the repository. There is no need to enable the user to specify a case-clashing file (wc-item) while another one is on-disk. Cheers, -- Johan
