We would seriously consider GitLab if they supported Mercurial. I am so annoyed with atlassian (another company that perhaps could pay attention more to developers). I like git for OSS but we love hg for our internal projects.
Would a migration tool or something similar help?
As an aside to the general HN readership, are there any good Mercurial hosts other than BitBucket?
[1] GitHub's down? https://news.ycombinator.com/item?id=9497821
I'd like to see a simple conversion tool that lets me configure everything (branch filters, user conversion, wildcards for what assets must go to LFS) that lets me convert a repo in TFS/SVN/HG into git with LFS.
The key here is integrated LFS. Without it, git is a complete no go for any shops that does lots of large versioned binaries. Git+LFS still seems like black magic to me, so it would be nice to see someone make a friendlier front for it.
Git is source control. It's for versioning source, not binaries. Built dependencies or artifacts or whatever else should be stored somewhere else like FTP.
(Tip for Unity users: The very first thing to do when you start a project is to go into the project settings and change it to Text Assets. That way the scene files and such will be text instead of binary. It's still a fairly opaque YAML format, but at least they will be more diffable.)
You are right that this is solvable with ftp, with one folder per revision and some scripting to manage committing source changes to git and binary changes to ftp but that is pretty much what git+LFS is!
Right, which is why I replied in the first place. The parent seemed to think LFS was black magic and didn't want to adopt git without it. In reality LFS is just another versioned file storage scheme similar to a Nexus repo or Linux distro package repo. Any FTP server and a script to push artifacts at the end of a build would get the job done.
> Any FTP server and a script to push artifacts at the end of a build
The binaries in this case aren't produced by the build, they are test input data, test output data, graphics files etc., and without them a developers' build or tests will likely fail.
So any time a developer updates his working copy (git pull, svn update, whatever) the the binaries need to be in sync, preferably automatically, since otherwise the source code itself is useless. It seems to me that LFS was designed to allow the user to not download all the binaries, but instead leave the small pointer files. That might be handy, but in my scenario I need ALL the binaries in place and up to date all the time. Basically I need to alias any syncing to also do the git lfs fetch.
Any time the user commits changes (svn commit, git push etc) the binaries must also be pushed.
I'd be very happy to adopt git but for acceptance within the organization it needs that seamless integration of binary versioning without extra steps, and also file locking.
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.
It allows you to use hg as a git client. It supports git branches (mapped to hg bookmarks), tags, etc and is mostly pretty seamless, with a few rough edges where the semantics don't quite match up --- e.g., hg supports moving tags, which git doesn't like doing.
I use it with github, and have done some pretty complex stuff with it, and nearly everything has Just Worked. The biggest problem is with the bookmark-to-branch mapping, so I tend to create/delete branches via the github web UI, then pull the repository to update the client, but I'm totally willing to admit that I've never really bothered to learn much about how that works so I could just not be driving it properly.
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?
First class windows support.
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.
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.