If there is a problem in connecting to the Subversion server,
e.g. credential or certificate related, the CLI client will pause to
ask the user for input on the console. This is not handled by bower
Subversion Resolver, causing the install process to hang forever
with no message printed to the bower user.
Running the Subversion CLI client with the option --non-interactive
will instead cause the client to exit upon such an error.This is
detected by the bower resolver and the message printed to the user,
making it much easier to investigate and solve the underlying problem.
Fix for bug #927. Ignore package if name matches specified in bower.json.
Permit fetch if package is explicitly declared in dependencies or devDependencies.
Designed for users who need tighter control of versions due to corporate liscence restrictions or other reasons.
Code Review Comments
Prior to this commit, when specifying a package version that cannot
be resolved, but other versions are available, the error message
did not state which what package failed, allowing for confusion.
For example, you might see:
```
bower ENORESTARGET No tag found that was able to satisfy 1.0.2
Additional error details:
Available versions: 1.0.1, 1.0.0
```
After this change, in the above situation the svn and git resolvers
will produce the following:
```
bower ENORESTARGET No tag found that was able to satisfy 1.0.2
Additional error details:
Available versions in somelib: 1.0.1, 1.0.0
```
Added logic to automatically detect smart Git hosts that allow shallow
cloning. This is done by sending an `ls-remote` request to the server
and then evaluating the returned HTTP header fields. For this, Curl
verbose logging is enabled for the `ls-remote` request, since Curl
verbose logging sends the returned HTTP headers to `stderr`.
If the `stderr` output contains the desired header
Content-Type: application/x-git-upload-pack-advertisement
then the server supports shallow cloning.
This approach uses Git and Curl for the heavy lifting. Instead of
implementing the request to the server using a simple HTTP client, Git
is used, since it takes care of authentication using stored credentials.
The used approach should also work for BitBucket, which only sends the
Content-Type header when a specific user agent is used. Using Git to
make the request enables this behavior.
The function to detect the smart Git host
(`GitRemoteResolver.prototype._supportsShallowCloning`) returns a
promise that is resolved when the server's request is evaluated. The
promise handling required an addition to `GitHubResolver.js` - to always
resolve the promise to `true`, since GitHub supports shallow cloning.
Added test cases to verify the new functionality.
