Looks to me like buckminster is trying to lock the local repository
multiple times. The local clone was not present, I intended to let
buckminster take care of this. Does the git reader not support multiple
searchPaths using the same repository?

On 2011-02-17 13:21, Daniel Weber wrote:
>
> Looks to me like buckminster is trying to lock the local repository multiple times. The local clone was not present, I
> intended to let buckminster take care of this. Does the git reader not support multiple searchPaths using the same
> repository?
>
AFAIK, it has never been tested so there's a distinct possibility that it doesn't work just yet. Our git support is
still in it's infancy and it builds on egit/jgit which is still in incubation and moving forward rapidly. It's all for
the good but help finding bugs, attached samples that provoke errors, and of course patches fixing such errors ;-) is
greatly appreciated. Nothing mandatory of course, but the more the better.

On 17.02.2011 14:22, Thomas Hallgren wrote:
> On 2011-02-17 13:21, Daniel Weber wrote:
>>
>> Looks to me like buckminster is trying to lock the local repository multiple times. The local clone was not present, I
>> intended to let buckminster take care of this. Does the git reader not support multiple searchPaths using the same
>> repository?
>>
> AFAIK, it has never been tested so there's a distinct possibility that it doesn't work just yet. Our git support is
> still in it's infancy and it builds on egit/jgit which is still in incubation and moving forward rapidly. It's all for
> the good but help finding bugs, attached samples that provoke errors, and of course patches fixing such errors ;-) is
> greatly appreciated. Nothing mandatory of course, but the more the better.
>
> Please enter a bugzilla for this and attach as much info as possible.
>
> Thanks,
> Thomas Hallgren

I can confirm this. When initially resolving a query where the git
repository is not yet present locally, concurrency issues ensue.

I've avoided this so far by setting the parallel resolver threads to 1.

IIRC, the problem I identified in the past is that the first resolver thread
starts cloning the repository, then the second thread tries to resolve
something else from it, sees that there already is a repository (and doesn't
know about or gets blocked by the other resolver still cloning) and tries to
checkout from it.

On 17.02.2011 15:40, Carsten Reckord wrote:
> I've avoided this so far by setting the parallel resolver threads to 1.

That seems to be a valid workaround, worked for me, too. Thanks!

> IIRC, the problem I identified in the past is that the first resolver thread
> starts cloning the repository, then the second thread tries to resolve
> something else from it, sees that there already is a repository (and doesn't
> know about or gets blocked by the other resolver still cloning) and tries to
> checkout from it.

On 18.02.2011 17:24, Daniel Weber wrote:
> On 17.02.2011 15:40, Carsten Reckord wrote:
>> I've avoided this so far by setting the parallel resolver threads to 1.
>
> That seems to be a valid workaround, worked for me, too. Thanks!
>
>> IIRC, the problem I identified in the past is that the first resolver thread
>> starts cloning the repository, then the second thread tries to resolve
>> something else from it, sees that there already is a repository (and doesn't
>> know about or gets blocked by the other resolver still cloning) and tries to
>> checkout from it.
>
> So has a bug been filed already?

No, I meant to file one and look into it further, too, but I haven't come
around to either yet. So feel free to go ahead and file one.