Aras Pranckevičius

I like Mercurial. It should be talked about more; instead of everyone talking about git only (when they aren’t busy talking about blockchains, that is). Let’s do more Hg marketing!

@aras Maybe add some #Hg pros that you've found as a starting point. 😜

I'm a #Git fan myself, and it's been years since I looked at #mercurial, so not sure what's in it for a team other than "safer history".

@aras I'm a PlasticSCM fan but Hg is definitely the best SCM among the open source ones.

@aras I thought about it when I was setting up my latest Bitbucket repositories but then got scared and went back to what I almost-sort-of-kind-of know.

@aras used mercurial before and liked it better, github was the killer feature in the end

@bartwe @aras Indeed, Github's feature set and population trumps most other concerns. I tried using Hg + Git for Github but in the end pure Git was simpler even though Hg was better.

@aras We use mercurial for the pyglet project, mostly for historical reasons. I sometimes wonder if it's costing us contributors due to many people only knowing git.

@aras how much of this is still true ? Can't see which large files have changed? Large file commits are super slow?

@dantreble I don't think I've experienced anything that they talk about there. We do use largefiles, some of them are gigabytes in size, and I haven't seen the "RAM needs to commit that are astronomical" issue.

And then it talks about how largefiles are primarily for saving bandwidth/CPU, whereas I think they are primarily for saving disk space. So... confused about what that post is about :)

@dantreble the "can't see which largefiles have changed" bit -- not sure what that is about. "hg status" shows state of largefiles just fine, etc.

@dantreble that said, for mercurial in particular, a more likely future proof extension is LFS, just because it reuses all the investment the world is putting into Git LFS.

@aras thanks for the sanity check. Svn has been great for us, but 2x diskspace on the client sucks. Last time I tried hg, you couldn't pull updates with any local modifications, that was a deal-breaker for artists. Might give it another try with myself and with artists 😃

@dantreble I don't think you'll get to less than 2x space overhead with either hg or git though. The largefiles/lfs things are to avoid 10-100x space overhead :)

@aras that's disappointing! I think our repository is maybe 5% text I bet all the text history for that 5% is less than 95% binaries duplicated. I bet I it comes under 2x :-)

@dantreble I'd still think that for game productions svn is probably easiest, and easiest to explain to people. DVCS are kinda too hard, and you almost never need the "D" part of it anyway. I mean if the internet is down, you can't work anyway for other reasons :)

@aras I'd lose the D with large file support. You caved quickly, "lets talk more about hg".. "meh, it's probably not for game production"!

@dantreble it's no more suitable for game production than git is, yeah :)

@aras @dantreble They also remove the requirement for large amounts of memory to merge large files.

@Tak @dantreble @aras I'm late to the party. I've got our small team of 4 fully switched over to hg+largefiles. They use TortoiseHg as their client and just refer to our VCS as "the Turtle". Integrated with Phabricator (brilliant software) so that we do all our task tracking / wiki / bugs in Phabricator. It's self hosted, behind Zerotier we get some more security than net-facing services, and it seems to just work for everyone. I was worried about pushing hg to a team, but its been pleasant.

@aras Just ran into this old toot of yours and I agree wholeheartedly! But where did you get this cool hoodie? :D

Sign in to participate in the conversation
Gamedev Mastodon

Game development! Discussions about game development and related fields, and/or by game developers and related professions.