[Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)
merged branch stloyd/bugfix/process_cwd (PR #6620)

This PR was merged into the 2.0 branch.

Commits
-------

880da01 [Process] In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process)

Discussion
----------

[2.0][Process] In edge cases `getcwd()` can return `false`

Bug fix: yes
Feature addition: no
BC break: no
Symfony2 tests pass: yes

In edge cases `getcwd()` can return `false`, then `proc_open()` should get `null` to use default value (the working dir of the current PHP process).

---------------------------------------------------------------------------

by stloyd at 2013-01-08T12:43:40Z

I guess that this could be related to #6496, as error code `267` at Windows means:
[`ERROR_DIRECTORY - The directory name is invalid.`](http://msdn.microsoft.com/en-us/library/ms681382%28v=vs.85%29.aspx#error_directory)

---------------------------------------------------------------------------

by Seldaek at 2013-01-08T12:57:38Z

If null already uses the current working directory, what's the point of calling getcwd() at all?

---------------------------------------------------------------------------

by stloyd at 2013-01-08T13:03:06Z

@Seldaek TBH. I don't have idea =) It seems that it's there _from the beginning_, but yeah, I was a bit confused by usage of it too...

---------------------------------------------------------------------------

by fabpot at 2013-01-09T08:13:24Z

What about removing the code altogether?

---------------------------------------------------------------------------

by stloyd at 2013-01-09T08:22:55Z

@fabpot I'm ok with that, just not sure it will not be an BC break...

---------------------------------------------------------------------------

by Seldaek at 2013-01-09T08:24:57Z

php.net says `or NULL if you want to use the default value (the working
dir of the current PHP process)` which sounds like getcwd() to me.

---------------------------------------------------------------------------

by Seldaek at 2013-01-09T08:26:32Z

For full BC though, `getWorkingDirectory` should `return $this->cwd ?:
getcwd();` Then at least if that call fails the whole process isn't
failing. I don't see why anyone would use that getter though.

---------------------------------------------------------------------------

by stloyd at 2013-01-10T12:43:59Z

@fabpot @Seldaek What do you think about this now?

---------------------------------------------------------------------------

by Seldaek at 2013-01-10T12:58:39Z

:+1:
Fix version_compare() calls for PHP 5.5.

Until PHP 5.5 hits beta, the version number for Git builds is still 5.5.0-dev,
which is less than 5.5.0alpha1 according to version_compare(). This means that
the branches for 5.5 aren't being executed on 5.5 snapshots at present.
merged branch LawnGnome/PHP-5.5-compat-2.0 (PR #6699)

This PR was merged into the 2.0 branch.

Commits
-------

c7bfce9 Fix version_compare() calls for PHP 5.5.

Discussion
----------

[2.0] [Form] [Locale] PHP 5.5 compatibility fixes

Bug fix: yes
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: unknown, can't run the test suite on 2.0 due to `Doctrine\DBAL\Logging\DebugStack` not being found
Fixes the following tickets: N/A
Todo: None
License of the code: MIT
Documentation PR: N/A

A backport of #6647 to the Symfony 2.0 branch, as requested. This affects a couple of files that aren't affected on 2.1.
[Console] fixed input bug when the value of an option is empty (closes #6649, closes #6689)
added a way to enable/disable PHP support when parsing a YAML input via Yaml::parse()

PHP support when parsing a file has been disabled by default.
If you do need PHP support when parsing a YAML file, enable it via:

    Yaml::setPhpParsing(true);

As of Symfony 2.1, PHP support is disabled by default, and support will
be removed in Symfony 2.3.
added a way to enable/disable object support when parsing/dumping

By default, object support is disabled, and instead of throwing an
exception when an object is handled, null is returned.

If you do need object support, enable it via:

    Yaml::dump($data, false, true);

If you want an exception to be thrown in case an invalid type is handled
(a PHP resource or a PHP object), pass true as the second argument:

    Yaml::dump($data, true, true);

The same can be done when parsing:

    Yaml::parse($data, 2, false, true);
Added Yaml\Dumper::setIndentation() method to allow a custom indentation level of nested nodes.

YAML does not specify an absolute indentation level, but a consistent indentation of nested nodes only: http://www.yaml.org/spec/1.2/spec.html#space/indentation/

Projects that are generally using 2 spaces for indentation should be able to retain consistency with their coding standards by supplying a custom value for the new $indent parameter added to Yaml::dump(), or the new Dumper::setIndentation() method.

The new parameter is a backwards-compatible API addition and defaults to the previous default of 4 (which was changed from 2 via PR #2242 only recently).

Conflicts:
	src/Symfony/Component/Yaml/Dumper.php
	src/Symfony/Component/Yaml/Yaml.php
[Yaml] fixed default value
updated CHANGELOG for 2.0.22
update CONTRIBUTORS for 2.0.22
updated VERSION for 2.0.22
[Yaml] fixed typo
[DependencyInjection] fixed a bug in the YAML dumper where references where not converted to the @ notation
[Yaml] fixed unneeded BC break
bumped Symfony version to 2.0.23-DEV
[Yaml] fixed #6770
[Yaml] fixed #6773
merged branch ezzatron/yaml-block-chomping (PR #6785)

This PR was merged into the 2.0 branch.

Commits
-------

ab0385c [Yaml] fixed #6773

Discussion
----------

[Yaml] fixed parsing of blocks with 'keep' chomping indicators (2.0 branch)

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6773
| License       | MIT
| Doc PR        | n/a

Also added a full set of tests for all combinations of literal/folded blocks and strip/clip/keep chomping indicators in both mid-file and end-of file positions.
merged branch ezzatron/yaml-negative-integers (PR #6784)

This PR was merged into the 2.0 branch.

Commits
-------

fea20b7 [Yaml] fixed #6770

Discussion
----------

[Yaml] fixed parsing of negative integers (2.0 branch)

| Q             | A
| ------------- | ---
| Bug fix?      | yes
| New feature?  | no
| BC breaks?    | no
| Deprecations? | no
| Tests pass?   | yes
| Fixed tickets | #6770
| License       | MIT
| Doc PR        | n/a

Note that an unrelated test fixture for large integers had to be changed to work on systems with 64-bit integer support because of the change from `assertEquals()` to `assertSame()`. Please see the diff for clarification.