3 ms·

> we love hg for our internal projects. We too use hg for our code. But I wouldn't say we "love" it - it works and we haven't found a compelling reason to swit

> we love hg for our internal projects. We too use hg for our code. But I wouldn't say we "love" it - it works and we haven't found a compelling reason to switch. So I'm curious, what about hg makes it great for some projects?

ergo14 10y ago
Big file support - this is important for asset management in game dev for example. First class windows support.
- jobvandervoort 10y ago
  Have you tried using LFS or Git Annex for big files instead? We've also built File Locking in specific to make it working with big assets a bit safer. Windows support in Git can definitely be improved, though luckily there are many great Git clients available nowadays.
  - marcinkuzminski 10y ago
    I think git LFS is having same issues as Mercurial Large Files had in the beginning. It's going to get there, but it takes time. We're considering that Mercurial LargeFiles support is much more mature. In regards to Git vs HG. We see that most of the users take advantage of plugin system that Mercurial has, eg Facebook with their plugins for handling huge monorepos. It also adds some advanced workflows, eg doing a code-review using phases and secret commits makes it much more pleasant to work compared to Git. FileLocking is quite easy with Mercurial actually. We're working on some other approach on this actually and want to work on a better system that emulates what SVN/Perforce have and bring it to Git and Mercurial with RhodeCode as the tool to have at least basic file permissions.
    - sytse 10y ago
      Just wanted to add that Christian Couder that is part-time on our team is working to integrate LFS into git itself to make it easier to use.
  - stonith 10y ago
    Not OP, but I tried Annex with Unreal 4 and the symlinks caused problems with the editor. Obviously that's a UE4 issue rather than an Annex issue, but it meant LFS was the only reasonable option at the time when I tested (~12 months ago).
- alkonaut 10y ago
  Big file support that works transparently without ever giving the feeling that it's tacked on. Real file locking support for those binaries is also critical.

ergo14 10y ago

Big file support - this is important for asset management in game dev for example. First class windows support.

jobvandervoort 10y ago
Have you tried using LFS or Git Annex for big files instead? We've also built File Locking in specific to make it working with big assets a bit safer. Windows support in Git can definitely be improved, though luckily there are many great Git clients available nowadays.
- marcinkuzminski 10y ago
  I think git LFS is having same issues as Mercurial Large Files had in the beginning. It's going to get there, but it takes time. We're considering that Mercurial LargeFiles support is much more mature. In regards to Git vs HG. We see that most of the users take advantage of plugin system that Mercurial has, eg Facebook with their plugins for handling huge monorepos. It also adds some advanced workflows, eg doing a code-review using phases and secret commits makes it much more pleasant to work compared to Git. FileLocking is quite easy with Mercurial actually. We're working on some other approach on this actually and want to work on a better system that emulates what SVN/Perforce have and bring it to Git and Mercurial with RhodeCode as the tool to have at least basic file permissions.
  - sytse 10y ago
    Just wanted to add that Christian Couder that is part-time on our team is working to integrate LFS into git itself to make it easier to use.
- stonith 10y ago
  Not OP, but I tried Annex with Unreal 4 and the symlinks caused problems with the editor. Obviously that's a UE4 issue rather than an Annex issue, but it meant LFS was the only reasonable option at the time when I tested (~12 months ago).
alkonaut 10y ago
Big file support that works transparently without ever giving the feeling that it's tacked on. Real file locking support for those binaries is also critical.