The Service Locator pattern and Dependency Injection clearly take a much different approach to achieving Inversion of Control and these differences often lead to philosophical discussions about which is better. Rather than tag either as "better", it is much better to look at the advantages and disadvantages that each bring to the table and understand that at different times and in different scenarios each will assert an edge over the other that makes it the most appropriate choice for that scenario.
One of the biggest advantages that I see in using Dependency Injection (at least when contructor injection is used as opposed to property injection) is that the component provides a very clear advertisement in the form of constructor arguments as to what external services that it needs in order to complete its job. This also allows the component to be independent of the mechanism used to provide Inversion of Control because it does not need to be aware of any IoC container or service locator implementation. If you're not using some sort of framework that is responsible for "building up" components and ensuring dependencies are resolved, the injection approach can also lead to having to invent ways to pass references down through several layers of application code in order to make the reference available to the code that depends upon it, which makes changes at the component level that require the introduction of a new dependency bubble changes through multiple levels.
The biggest advantage that I see in the Service Locator pattern is a direct counter to the advantage of using Dependency Injection. Because the component does not advertise the dependencies that it has on external services to complete its work the code adheres more closely to the concept of encapsulation. By advertising external dependencies required to complete work, it can be said that that components using Dependency Injection reveal a bit more of "how" the work is done instead of leaving the entire focus on "what" work is to be completed. Using the Service Locator approach, there is no need to ensure that service references are passed from layer to layer that may not need them. This advantage to some degree is countered by the fact that many developers using Inversion of Control will also be using some sort of framework that will handle resolution of dependencies. Additionally, by removing the explicit advertisement of dependencies on object construction the risk of finding that a necessary service has not been registered late in the process increases and the component cannot "fail early".
All other things being equal, I find that my preferences lean to the explicit model provided with constructor injection and allow whatever IoC container that I am using handle many of the drawbacks of this approach. This allows me to quickly look at the method signature of the constructor for any class that I have built using this model and understand what it needs to get its job done - a big advantage when trying to quickly understand problems with production code. There are some times when you find that your component MUST support a public constructor with no arguments and others when it is not required but does make sense to do so. In these cases, the Service Locator becomes a valuable tool to make services available to your component.