Am 02.08.14 14:52 schrieb <nkadel_at_gmail.com>:
>On Fri, Aug 1, 2014 at 3:05 AM, Pflästerer, Karl
><Karl.Pflaesterer_at_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
Received on 2014-08-02 17:04:04 CEST