The general rule when creating entities and repositories is that the Entity class must contain the logic necessary for working on one Entity, and the Repository classes contain the logic necessary for working with Entities groups.
A simple example:
If you want to convert the price of a product from a dollar to a euro, you will have BasketItem::convertCurrencyTo($currencyType) . This is code that works with one Entity.
If you want to find all BasketItems with prices ranging from $ 10 to $ 20, you should use BasketItemRepository::findByPriceRange($min, $max) . This is the code that works with the Entities group.
IMO, things can get a little confusing when working with Entities that have a one-to-many or many-to-many relationship. I would suggest that one Basket has many BasketItems , and one User has one Basket . Therefore, I consider it reasonable to assume that in order to interest BasketItems a User , you can do something like this:
$user->getBasket()->getBasketItems() .
Please note that in this example the repository is not used, because it is a very simple query. If you need to do something more specific, for example, find BasketItems a User who is interested in selling, you can use something like BasketItemRepository::findWhereOnSaleForBasket($BasketId) . There is nothing stopping you from adding a similar method directly to the User or Basket classes, but I feel that since your main goal request is BasketItem , it belongs to this class of object repository.
You note that implementing a shopping basket is a small task, and you are right. But the questions you ask are not really limited to Symfony2 (in this case it is more about Doctrine 2), so I think it would be useful if you look at other open source carts and learn what they do. I think the only impact that Symfony2 really has is to make you decide how to split the code inside the packages.
Hope this helps!