4 ms·

FWIW: It seems like none of these issues are related to largefiles. It might be problems with the eclipse plugin or "something else" (configuration issues, bad

FWIW: It seems like none of these issues are related to largefiles. It might be problems with the eclipse plugin or "something else" (configuration issues, bad interaction with other tools, incompatible versions, bugs). The only exception could be lack of history. Largefiles make some tricks with storing the hash of file X in a .hglf/X file and folding it back in the right namespace is tricky and had some errors. Annotate and largefiles are conceptually incompatible; largefiles is intended for big and binary files where annotate wouldn't work no matter what. My experience is that the main problem with largefiles is the problem it is trying to solve. It is not a good idea to store large files in a VCS - especially not in a DVCS. Storing large files in VCS is last resort. Given a situation where you have to / want to do it anyway, largefiles is a fine solution. It works quite well for us and without significant problems.

neandrake 11y ago
Maybe I misread durin42's post - I thought they were asking about issues I mentioned with hg + editor plugin. There have been issues with the plugin for several years that I had moved away to primarily just using the command-line by the time it was decided to use largefiles. I'm not aware of any specific largefiles + editor plugin issues, other than a suspicion about things getting slower with regards to looking at history. One other thing that's been a problem in the past with hg + largefiles (or only started happening since around when we turned on largefiles): Cloning a largefiles repo using "--uncompressed" flag would re-open all the closed named-branches in the newly cloned repo.