fixed some grammar + tweaks
removed ending 's'
reverted sentence
updated VENDORS for 2.0.5
updated vendors to dev branches
bin/vendors: break if a bundle has local modifications

I'm often developing several Symfony2 bundles at once. I have them all
set up as deps for a single Symfony2 application, and I point Netbeans
at the base of the Symfony2 directory.

Since each [sub]dir in vendor/ is a complete git repository, after
making a bunch of changes I can then dive into each dir and commit/push
as necessary.

If I accidentally run "bin/vendors install" while I have un-pushed
changes, they're blown away by the "git reset --hard" in bin/vendors.
This patch proposes to make the script more cautious, assuming that
local modifications should never be blown away. Note that "--force" is
unimplemented, this is just one idea.
moved DemoBundle ControllerListener in a EventListener subnamespace
updated VENDORS for 2.0.6
updated vendors to dev branches
updated deps
cleaned HTML rendering
Update web/config.php
merged branch meonkeys/2.0 (PR #232)

Commits
-------

29dd189 bin/vendors: break if a bundle has local modifications

Discussion
----------

bin/vendors: break if a bundle has local modifications

I'm often developing several Symfony2 bundles at once. I have them all
set up as deps for a single Symfony2 application, and I point Netbeans
at the base of the Symfony2 directory.

Since each [sub]dir in vendor/ is a complete git repository, after
making a bunch of changes I can then dive into each dir and commit/push
as necessary.

If I accidentally run "bin/vendors install" while I have un-pushed
changes, they're blown away by the "git reset --hard" in bin/vendors.
This patch proposes to make the script more cautious, assuming that
local modifications should never be blown away. Note that "--force" is
unimplemented, this is just one idea.

Also see my recent post about same to the symfony-devs mailing list.

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

by Problematic at 2011/11/11 12:33:11 -0800

I'm -1 on this; I feel like bin/vendors should never contain user modifications, and so I WANT any changes that have crept in to be blown away. Any time I've been tempted to write hacky code as a shortcut, this deters me and forces me to find a cleaner way to handle things :)

In development, I usually point the autoloader to a local path on my machine where I'm making changes (you can even pass it an array if you have some production bundles and some in development within the same namespace, though you have to be careful with this because odd things can and do happen). Then I can easily isolate my work (into a new Netbeans project, for example), commit at will, and not be at risk of losing work from a rogue `php bin/vendors install` call.

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

by meonkeys at 2011/11/11 20:23:29 -0800

I like your autoloader suggestion! I'll give that a shot.

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

by meonkeys at 2011/11/17 13:03:45 -0800

See also: <https://groups.google.com/d/msg/symfony-devs/bd8uu5khdeI/kFCuexhibfIJ>
tweaked previous merge
merged 2.0
updated vendors
bin/vendors: speed up: fetch only when necessary

If a bundle's HEAD is already at the version specified in deps or
deps.lock, don't fetch more commits from upstream.

This performance improvement only helps when the version specified is an
SHA-1 checksum (as opposed to a branch or tag name), but that turns out
to be quite often (especially if update/deps.lock is used).

This does not handle the case where upstream contains modified history
(e.g. missing commits), but neither does the rest of bin/vendors.
merged branch meonkeys/2.0 (PR #242)

Commits
-------

2651554 bin/vendors: speed up: fetch only when necessary

Discussion
----------

bin/vendors: speed up: fetch only when necessary

If a bundle's HEAD is already at the version specified in deps or
deps.lock, don't fetch more commits from upstream.

This performance improvement only helps when the version specified is an
SHA-1 checksum (as opposed to a branch or tag name), but that turns out
to be quite often (especially if update/deps.lock is used).

This does not handle the case where upstream contains modified history
(e.g. missing commits), but neither does the rest of bin/vendors.
Do not take untracked files into account
updated VENDORS for 2.0.7