[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] locking mechanism
|
Hi all,
I didn't expect this thread to spawn so many sub-questions... Just goes
to show the diversity of people here I guess :).
My original issue is independent from whether we keep the deletion hook
or not, or whether we add a hook for additions, or whether we have a
hook for moves... As Stefan said, some kind of a reentrant DirCache lock
is what I'd need, I don't think this is specific to the model-aware
merging I'm trying to achieve : this would most likely be encoutered at
one point or the other by anyone trying to integrate his tool with
E/JGit. If E/Jgit has started an operation that locked the dircache, any
hook or higher-level delegation (such as what I'm doing) will encouter
similar issues; which will be worsened as E/Jgit evolves : if we add a
hook to auto-stage moves, this will be one more thing that could
potentially try and "re-lock" an already locked DirCache.
I will be unable to answer here for the next two weeks and won't be able
to monitor gerrit either, but I will try and put such a change together
when I return.
Until then, I wish you a happy new year ;).
Laurent Goubet
Obeo
On 20/12/2013 13:16, Robin Rosenberg wrote:
----- Ursprungligt meddelande -----
Från: "Stefan Lay" <stefan.lay@xxxxxxx>
Till: "Robin Rosenberg" <robin.rosenberg@xxxxxxxxxx>, "EGit discussion" <egit-dev@xxxxxxxxxxx>
Skickat: fredag, 20 dec 2013 12:50:34
Ämne: locking mechanism
But this preference wouldn't help Laurent in his problem of locking. We
cannot tell the user
that model merge only works when this preference is set.
Seems this thread is about everything..
A quick
No...
solution to solve this problem could be to add a flag to the
GitMoveDeleteHook to
switch off auto staging programmatically. But this seems more like a hack
for this concrete problem
which may even cause additional problems, e.g. with threading behavior.
Isn't the issue here that he needs to get access to the lock, not override
the auto-staging?
A better solution would be to implement a reentrant DirCache lock as
Laurent proposed already.
The method DirCache.lock could check if it was already called in the stack
of the thread and
in that case just return the instance which was created in a
previous call in this thread. Only the last unlock call would delete the
lock file.
I think that would work.
-- robin
_______________________________________________
egit-dev mailing list
egit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/egit-dev
begin:vcard
fn:Laurent Goubet
n:Goubet;Laurent
org:<a href="http://www.obeo.fr";>Obeo</a>
email;internet:laurent.goubet@xxxxxxx
url:http://www.obeo.fr
version:2.1
end:vcard
