Thanks for the follow up ideas. We also decided to access the repos through ssh. With that, there is no delay at all. Regards, Tamas On 13 June 2013 16:29, Thomas Rast <trast@xxxxxxxxxxx> wrote: > Tamas Csabina <tcsabina@xxxxxxxxx> 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 [1], 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[2]). > > 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. [3]. 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[4]) 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). > > > > [1] http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id2615667 > > [2] http://thread.gmane.org/gmane.comp.version-control.git/212109 > > [3] http://thread.gmane.org/gmane.comp.version-control.git/223299 > > [4] http://gitolite.com/gitolite/ > > -- > Thomas Rast > trast@{inf,student}.ethz.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html