Am 02.08.14 14:52 schrieb <nka...@gmail.com>:
>On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl ><karl.pflaeste...@dfv.de> wrote: >> Hi, >> >> I created a file with the name http<->https.conf and committed it under >> MacOS. No prolem at all. >> I could checkout the file on out Linux servers. > >*WHY* do you insist on doing something guaranteed to be incompatible >across operating systems? Punctuation in file names is anathema to >good programming practices. characters like '>', '!', '()", '[]", >quotation marks, spaces, etc. are all known to cause problems for >locally written pre-commit and post-commit scripts and should be >avoided as a matter of course. I tried the filename under MacOS and Linux; no problem. At that moment I didn’t think of Windows. The filename was just simply explaining what the file was for: some mod_rewrite rules for jumping between a SSL and non SSL http process. >> But most of my colleagues use Windows. As they tried to update their >> working copies everything stopped. > >They, or you, need to send a command to the upstream repository to >delete or remove the file there, not to manipulate it inside the local >working copy. But yes, the potential for screwing up local working >environments of various kinds is why you >Do-Not-Put-Punctuation-In-File-Names.txt. Deleting the file was easy. That was not the problem. The problem was as I described the state of the WC. They could neither go one version back no forward. > >> Because <> are not allowed under Windows in filenames svn could not >>create >> the file. But they also couldn’t cleanup the WC. >> The working copy was completely broken (für svn) and they had to >>checkout >> everything new. > >If you're willing to test, you might try what I just suggested. See if >you can switch back to a tag or revision without the forbidden >filename in it, as well. We tested some variants (even a sqlite db from a fresh checkout). > >> IMHO this is a bug. At least svn under Windows should have refused to >> checkout that file. > >That's a reasonable point. Would it have been possible for them to to >checkout their working copy to an earlier branch, tag, or revision >that did not contain the file? Would you be able to test that? Yes we tested it. As I wrote. They could not go back, because they had to cleanup first. But they couldn’t cleanup because cleanup couldn’t finish the transaction. If I would have known the sqlite db og subverison better I would have tried to correct in the db. > >> Furthermore: the cleanup command didn’t work because svn could not a >>file >> with that name. I would have expected cleanup to revert a transaction >>not >> to complete it. > >Workarounds for system limitations can lead to a lot of complexity in >upstream code can be extraordinarily destabilizing. Patches like that >would have to be done very carefully, and could require extensive >maintenance. Not saying it's not reasonable, but an error in such a >patch could break other working code in other operating systems. I understand that but what would habe happened if I had committed such a file to a public repository? That’s kind of remote DOS attack for windows user. KP
