Skip to content

[Debug] Replaced logic for detecting filesystem case sensitivity #18126

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

blowski
Copy link

@blowski blowski commented Mar 12, 2016

Q A
Branch master for features and deprecations / lowest applicable and maintained version otherwise
Bug fix? yes
New feature? no
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets none
License MIT
Doc PR none

When I cloned the master branch onto a Virtualbox Vagrant OSX El Capitan host, Ubuntu Wily guest, the Symfony\Component\Debug\Tests\DebugClassLoaderTest::testFileCaseMismatch failed because 'Failed asserting that exception of type "\RuntimeException" is thrown'.

@wouterj confirmed he got the same problem, and it's because Virtualbox shared folders aren't case sensitive, even when the guest is using a case sensitive filesystem. So I've replaced the logic that looked at the name of the operating system.

I ran the tests in the following environments:

  • Virtualbox/Vagrant - OSX Host, Ubuntu guest
  • Virtualbox/Vagrant - OSX Host, Windows guest
  • OSX native
  • Ubuntu native

NB - I didn't run it on native Windows (because I don't have easy access to one).

Dan Blows added 2 commits March 12, 2016 15:24
When I cloned the master branch onto a Virtualbox Vagrant OSX El Capitan host, Ubuntu Wily guest, the `Symfony\Component\Debug\Tests\DebugClassLoaderTest::testFileCaseMismatch` failed because 'Failed asserting that exception of type "\RuntimeException" is thrown'.

@wouterj confirmed he got the same problem, and it's because Virtualbox shared folders aren't case sensitive, even when the guest is using a case sensitive filesystem. So I've replaced the logic that looked at the name of the operating system.

I ran the tests in the following environments:
* Virtualbox/Vagrant - OSX Host, Ubuntu guest
* Virtualbox/Vagrant - OSX Host, Windows guest
* OSX native
* Ubuntu native

NB - I _didn't_ run it on native Windows (because I don't have easy access to one).
When I cloned the master branch onto a Virtualbox Vagrant OSX El Capitan host, Ubuntu Wily guest, the `Symfony\Component\Debug\Tests\DebugClassLoaderTest::testFileCaseMismatch` failed because 'Failed asserting that exception of type "\RuntimeException" is thrown'.

@wouterj confirmed he got the same problem, and it's because Virtualbox shared folders aren't case sensitive, even when the guest is using a case sensitive filesystem. So I've replaced the logic that looked at the name of the operating system.

I ran the tests in the following environments:
* Virtualbox/Vagrant - OSX Host, Ubuntu guest
* Virtualbox/Vagrant - OSX Host, Windows guest
* OSX native
* Ubuntu native

NB - I _didn't_ run it on native Windows (because I don't have easy access to one).
@javiereguiluz
Copy link
Member

@blowski thank you for contributing to Symfony! Before reviewing your pull request, I'd like to comment you two little things:

  1. You left the original message ("master for features and deprecations / lowest applicable and maintained version otherwise") in the Branch row of the table. However, this row must contain the name of the branch you think it's the most appropriate to merge this. These are the rules:
  • If it's a new feature, select "master"
  • If it's a bug, select the oldest (but maintained) Symfony branch which suffers that error.

In this case it's a bug so: if 2.3 suffers this problem, select 2.3. If not, the next maintained branch is 2.7.

  1. That's the second issue I wanted to tell you. You based your fix on the 2.5 branch of Symfony. Problem is that this branch is no longer maintained. Currently we maintain 2.3, 2.7, 2.8, 3.0 and master. In this page you can see more information about the Symfony versions: http://symfony.com/doc/current/contributing/community/releases.html#version-history

@blowski
Copy link
Author

blowski commented Mar 12, 2016

@javiereguiluz Thank you - I just had a chat with @weaverryan and he said the same thing, so I created another PR against 2.7 (#18130). And I fixed the message as well, sorry about that.

Thanks for organising today by the way, really useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants