It would severely hurt our velocity if we'd decided to support Mercurial, whilst the benefit is only for a small group of potential users. We're not planning to support hg.
A git migration tool would be terrific: I'm on a svn project with a 20Gb history, 3Gb working copy, with TONS of versioned binary assets. The migration story to git is a nightmare with lots of different tools and utilities that reportedly do some part of the migration, but don't play well together.
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.
> Without it, git is a complete no go for any shops that does lots of large versioned binaries.
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.
For some of us, binaries are source. For example, anyone developing in Unity or Unreal Engine has large binary files that represent the game levels, blueprints, and other assets. These aren't generated files, logically they are source code that should be versioned along with the textual source code.
(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.)
Build artifacts aren't necessary to bring over to git in a conversion from hg/svn. I archive installers and other artifacts in svn, but if I moved to git I'd just archive those somewhere else. The binaries that are actually part of the build (a few binary dependencies, lots of graphics, test in/out data etc) must be next to the source however because those are needed to reproduce a build.
That's why I (and many others) need Git+LFS - because I need a lot of versioned artifacts such as images and binary application documents. One example is test inputs and outputs if you have an app that produces and consumes binary data. Every revision of the source tree needs the right revision of the corresponding binaries.
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.
I meant it seems like black magic to get it set up properly. Especially on windows.
> 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.
I'm not the original poster but some of us prefer Mercurial's workflow to git's, so a migration tool, while nice to have as an option, isn't what would help win customers like us. (I do like the direction that GitLab is taking, though.)
As an aside to the general HN readership, are there any good Mercurial hosts other than BitBucket?
RhodeCode is self-hosted, but you can run it in Azure/Amazon cloud. For large companies, that setup might prove even more stable than relying on someone else's cloud [1]
Would a migration tool or something similar help?