String parsing was a little error prone, so we'd prefer to ask the
bazaar repository whether a particular string is a valid revision ID.
To do this, we need a very slightly custom version of
disambiguateRevision for *bzrSource.
This revision also refactors TestSourceManager_InferConstraint pretty
dramatically to let it work on repositories coming from different
VCSes.
The previous commit changed the order of prefernce when inferring
constraints. Also, moved the bazaar GUID parsing stuff to make sure
that it receives the same preference level as revisions for other
repository types.
commitInfo returned a struct from an external package. This coupling isn't
ideal, and we wouldn't use the extra info for anything. It's better to just have
a method for exactly what we want, which is disambiguation of short revision
specifiers.
While dep doesn't want to encourage the use of abbreviated git commit
identifiers, they come up frequently when we parse vendoring specifiers (like
glide.yaml) of existing projects. We should give a shot at parsing these and
then expanding them to their unabbreviated form.
This addresses an issue where the godep importer would confuse semver
suffixes for being bzr revisions.
Now we have stricter checks on the bzr revision checks which will be able to
distinguish between semver with a suffix and a bzr revision. The new check
enforces bzr revisions to contain an @ symbol.
When a user supplied string in an imported config file, or specified to
dep ensure, can be interpreted multiple ways, prefer the branch over a
semver constraint.
In #710, glide.yaml specified v2 for https://github.com/go-mgo/mgo.
When we assume that is a semver constraint, solve fails because the
hinted revision in the lock (a commit on the v2 branch) doesn't satisfy
the assumed constraint of ^2.0.0.
The new preferred match order for the user string is:
* revision
* branch
* semver constraint
* tag
I am giving preference of a semver constraint over a tag so that a bare
version, 1.0.0, is interpreted more loosely with an implied caret,
^1.0.0, instead of the stricter exact match.