Thanks for the follow up ideas.
We also decided to access the repos through ssh. With that, there is
no delay at all.
On 13 June 2013 16:29, Thomas Rast <tr...@inf.ethz.ch> wrote:
> Tamas Csabina <tcsab...@gmail.com> writes:
>> Meanwhile I`ve figured it out that the sluggish post-receive execution
>> was due to a (mis)-configuration in the samba share where the remote
>> repository is hosted. These are:
>> oplocks = No
>> level2 oplocks = No
>> Now, do I have to worry about allowing oplocks on the remote
>> repository from the git point of view? Thinking about concurrent push
>> operations from different developers?
> From a brief glance at the relevant docs , it would seem that oplocks
> are actually just an implementation detail for safe (in the context of
> parallel access) client caching. So they should be fully transparent to
> any application usage. However, the docs do mention that you may be in
> trouble if the connection to the server times out.
> That being said, some FSes see more usage and thus have been tested more
> in this context, and git does tend to show some pretty weird issues on
> broken network FSes (one such case: Lustre).
> In addition, there are some known races w.r.t. the handling of refs, and
> of pruning, if you run git-gc while concurrent pushes are going on.
> Jeff King and Michael Haggerty are currently working on getting them
> fixed, see e.g. . To see these, you'll have to hit the repo much
> harder than a small team can.
> So it *should* work, at least if you disable gc.auto and run git-gc
> manually at some safe time. But I wouldn't be surprised if there are
> bugs lurking in the context of Windows usage on a Samba-hosted repo,
> which sounds like a very rare combination.
> And in any case, don't take my word for it; if your life or company
> depends on this, you'll need to do your own testing to ensure that it
> holds up.
> Oh, and why do it that way? You would most likely get much better
> performance out of it if you hosted the repo over ssh (e.g. with
> gitolite) or a smart-http server, since the expensive operations (and
> they are *expensive*) would be completely local to the server. The
> tradeoff there is that it also shifts a lot of CPU work to the server,
> but if you can afford it, you should see a great speedup especially when
> fetching large amounts of data (e.g. at cloen time).
>  http://thread.gmane.org/gmane.comp.version-control.git/212109
>  http://thread.gmane.org/gmane.comp.version-control.git/223299
>  http://gitolite.com/gitolite/
> Thomas Rast
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html