twitter/bower — pull request #89 by satazor (2012-10-09 23:09:23+00:00)
Title: Unit of work strategy implementation

The current twitter implementation of bower resolves dependencies in parallel and isolated.
This leads to several problems when this happens:

Dep A and B both depend on Dep C.

Since dependencies of A and B are resolved individually, both repositories will be cloned twice, copied twice, etc, unnecessarily. Also sporadic errors occur when the copy process is being done at the same time, resulting in stream and pipe errors (see issue #81).

This PR fixes this by adding a new class called UnitWork (unit of work) that is a simple storage with lock and unlock ability.
When both Dep A and Dep B attempt to resolve Dep C, one of them will be locked waiting for the other. If Dep A gain the lock first, it would release the lock and store information about the resolved status. When B gets notified that the lock was released, he will noticed that it has been resolved before by someone else. If the version is incompatible with the one resolved, an error is thrown (e.g.: Dep A requires version 1.0.0 of C and Dep B requires version >= 2.0.0 of C).

More tests should be added to this.
Tell me what you guys think about it