On 15 November 2014 10:01, Junio C Hamano <gits...@pobox.com> wrote: >> 23 files changed, 375 insertions(+), 7 deletions(-) > > I am not sure if this much of code churn is warranted to work around > issues that only happen on repositories on NFS servers that do not > keep open-but-deleted files available. Is it an option to instead > have a copy of repository locally off NFS?
Unfortunately not providing delete-on-last-close semantics is true for most (all?) NFS servers that are accessed by multiple clients. NFS v3 is stateless so the server has no way of tracking open files accross clients and the silly rename work around only works within a single client. NFS v4 could support delete-on-last-close semantics but I’m not sure if there are actual implementations providing that. (This is based on my admittedly limited understanding of NFS, I’d love to learn that I’ve got this wrong). We are susceptible to the same problem accessing shared repositories from multiple clients so we certainly appreciate the use case. Unfortunately copying repositories to the local nodes is not something that’d be feasible. Is there another/better approach solving this problem? -- 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
