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.
> 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.
> 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.
> 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?
> 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.
Received on 2014-08-02 14:52:48 CEST