On Tue, Jan 23, 2018 at 01:24:24AM -0800, Attila Törcsvári wrote: (Reformatted for better readability.)
> After several days I have found the reason why we cannot use git version > control on exist db mapped drive. [...] >> - Windows (most probably does not matter) >> - p: drive is a mapped eXist XML DB WebDAV drive, [...] >> *Possible reason* >> >> exist uses Milton. >> exist WebDAV improperly reports size of file as found in >> http://exist-db.org/exist/apps/doc/repo/webdav.xml >> “The size of an XML document is presented as a multiple of 4096 bytes, [...] > Any ideas? Not sure why you did not include the link to the Git-for-Windows issue from where you have obtained that information [1], but no, as stated by the GfW maintainer, | That is really unfortunate. Git relies on accurate file size information, | it cannot function without it. | | I guess there are only two ways out of this: | | get eXist to fix this, or | stop using Git on drives mapped into eXist's database. Now, with a bit of patience and the keywords "exist", "webdav" and "4096" at your hand, you should be able to find the discussion [2] happened on the mailing list of the exist-open project. A post in it [3] mentions two interesting things: - That eXist thing supports sort of black list of clients — detected by looking at the User-Agent header field in their HTTP requests, which break when the PROPFIND WebDav requests they ussue use that extravagant approach at returning an approximate size. - For those "blacklisted" clients, eXist switches to a mode which calculates exact resource size, and in that mode, «all XML documents in a collection are serialized to determine the exact sizes of these documents» and «you would find performance much worse than with a WebDAV client that doesn't care about the exact size of a document». For me, two takeaways to do would be: - You may get in touch with the eXist devs and discuss this issue with them. I really have no idea how that eXist thing stores the files a client puts to it. It looks like it actually "looks into" XML documents which are stored into it and somehow stores them in a "parsed" form to that getting their exact size requires actually serializing them to byte streams — as for streaming to the client — to calculate the size of the result, and then throwing it away. _May be_ eXist goes clever when it sees a binary file, or may be it is possible to configure it in a way to consider all files in a particular directory to be opaque binary blobs. Or it may be possible to ask them to "blacklist" Git-for-Windows in the same way Mac OS X's Finder app is "blaclkisted." In other words, I would ask whether and how it's possible to make eXist report precise file sizes when GfW asks for them. - It appears that unless eXist may be somehow made not look into the files it manages, working around the issue — say, by faking the User-Agent field Git uses in its HTTP requests — has a great chance of slowing things down. All-in-all, I see no real reason in trying to fix what it appears to be very broken right from the start. Instead of battling astoundingly weird "remote Git on a network drive backed by WebDav" setup, it would be better to spend your energy on convincing your management to switch to a more sane setup. In corporate setups, Git can be made use SSO when authenticating against HTTP servers, so control freaks may control what they want just fine without hampering the users or lowering the level of security. And this setup will work _much_ faster than the nonsense you have deployed at the moment. 1. https://github.com/git-for-windows/git/issues/1452 2. https://sourceforge.net/p/exist/mailman/message/30591159/ 3. https://sourceforge.net/p/exist/mailman/message/30591698/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
