Re: [egit-dev] Relationship of Pulling and Open Project

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

Thanks Matthias. Finally found the time to file the bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=510592

On Thu, Dec 22, 2016 at 10:58 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:
> yes
>
>
> On Thu, Dec 22, 2016 at 10:27 AM, Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
>>
>> Thanks Matthias for the detailed description. Shall I open a bug to
>> capture you suggestion to run fetch outside the lock during the pull
>> operation?
>>
>> Best regards, Lars
>>
>> On Wed, Dec 21, 2016 at 11:12 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx>
>> wrote:
>> > On Wed, Dec 21, 2016 at 4:04 PM, Lars Vogel <lars.vogel@xxxxxxxxxxx>
>> > wrote:
>> >>
>> >> Dear EGit developer,
>> >>
>> >> I noticed that I cannot open a closed project during a Git Pull
>> >> operation. See screenshot.
>> >>
>> >> Is this intended or a undesired side effect?
>> >
>> >
>> > EGit's PullOperation locks all projects versioned in the repository
>> > (ies)
>> > the operation was started for.
>> > Project.open tries to obtain the same lock
>> > (IResourceRuleFactory.modifyRule(this)) and hence has to wait.
>> >
>> > EGit locks the projects since
>> > - pull typically modifies files in the affected projects and could
>> > interfere
>> > with other jobs which also modify files in the same projects
>> > - operations modifying the git index of the same repository can't run
>> > concurrently.
>> > The latter is also ensured by JGit by locking the index file.
>> >
>> > The advantage of this pessimistic locking is that we prevent partial
>> > execution of the pull operation.
>> >
>> > EGit's PullOperation calls JGit's PullCommand. Pull consists of a fetch
>> > command followed
>> > by a merge or rebase command. Typically fetch takes much longer than
>> > merge
>> > or rebase
>> > so instead of pessimistically locking the affected projects for the
>> > complete
>> > runtime of a pull command
>> > we could run fetch without any scheduling rule (fetch doesn't modify
>> > files
>> > in the workspace but only
>> > downloads new git objects) then acquire the lock on the affected
>> > projects
>> > and if this succeeds run
>> > the merge or rebase command. If we can't get the lock we would need to
>> > fail
>> > the lock and ask
>> > the user to retry later. This could be implemented in EGit by running
>> > JGit
>> > FetchCommand followed
>> > by a MergeCommand or RebaseCommand. Alternatively we could enhance
>> > JGit's
>> > PullCommand
>> > with a callback enabling EGit to acquire the lock after fetch finished
>> > and
>> > before merge/rebase is started.
>> >
>> > -Matthias
>>
>>
>>
>> --
>> Eclipse Platform UI and e4 project co-lead
>> CEO vogella GmbH
>>
>> Haindaalwisch 17a, 22395 Hamburg
>> Amtsgericht Hamburg: HRB 127058
>> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
>> USt-IdNr.: DE284122352
>> Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web:
>> http://www.vogella.com
>
>



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com