Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's New in Mercurial 3.0

hglabhq.com

Post reply on HN
Print view View original

81–90 of 118 posts

Re: What's New in Mercurial 3.0

#81

Post by tomlu »

wtallis wrote: post #78
tomlu wrote: post #64

Earlier quoted context omitted.

> There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control Why do you say it's bad practice? Game assets come to mind, these aren't derived artifacts and you can't build the game without them.

Usually, you can build the game without them, up to the final packaging stage. Almost any game that is built on an engine can have all of the asset files swapped out without having to recompile anything, and as long as the file format and structure for assets is relatively stable there doesn't have to be a tight coupling between engine versions and asset versions except when doing QA and benchmarking. This is one of…

There usually are dependencies between the game and its assets, but sure, these dependencies can be managed.

Historically I've dealt with the problem by keeping code and assets in separate repositories (using different version control systems). While it's worthwhile to do so in order to use git for code it really is a pain.

Re: What's New in Mercurial 3.0

#82

Post by mpdehaan2 »

Crito wrote: post #28
mpdehaan2 wrote: post #24

Earlier quoted context omitted.

This is probably due to an understanding of rebases, rebases should be used to bring your commits to the top of the stack for easy review in OSS projects. Amazingly useful for making sure patches are easy to apply while following a remote branch. My biggest problem with hg is the lack of real topic branches and how they become impossible to delete -- and having to use things like quilt on top to try to make local bra…

Wait, "quilt" as in the tool that manages patch files? That's still in use? Or is quilt a new Hg extension?

I think I meant queues. I was looking for the plugin and failing to find it, but it was basically a thing like quilt but an Hg extension. Was not a fan :)

Re: What's New in Mercurial 3.0

#83

Post by kyrra »

novaleaf wrote: post #75
kyrra wrote: post #65

Earlier quoted context omitted.

Mercurial has the LargeFiles extension[0]. This ships with Mercurial by default, just disabled. This does help some. [0] http://mercurial.selenic.com/wiki/LargefilesExtension

while i like LargeFiles, it's really not enough. Support for binary content (and indeed, history truncation) needs to be native. As it stands, LargeFiles can only be used on intranet networks, and if you've ever used it for any serious purpose, you'll run into corruption. It's really disappointing to see 3.0 announced with no solution to this.

Why intranet only? The data still comes from the HG server through standard means.

And what kind of data corruption do you see? It tracks files by their SHA1 value and downloads them as needed. Did you report any corruption issues you hit? Or have links to anything specific?

Re: What's New in Mercurial 3.0

#84

Post by qrohlf »

gecko wrote: post #35
wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…

Relevant: http://stevelosh.com/blog/2013/04/git-koans/

Re: What's New in Mercurial 3.0

#85

Post by EGreg »

Fice wrote: post #49
EGreg wrote: post #6

Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!

For me, the extreme popularity of GitHub is the No. 1 reason to avoid it as I do not want to contribute to the centralization of the Web. Also I like Fossil's [fossil-scm.org] approach of integrating wiki and bug tracker into DVCS, which allows projects to be less dependent on hosting services.

There is no decentralized system yet for social networking:

Identity, Authentication, Privacy, Subscriptions, Notifications, Contacts, Invites etc.

That's what we're working on at Qbix

Re: What's New in Mercurial 3.0

#86

Post by frik »

Has Facebook switched to Mercurial? In one news it says so, in the next one read it has a ~50GB Git repo. If they really switched, it would be a good advertisement for Mercurial and its capabilities.

Re: What's New in Mercurial 3.0

#87

Post by alwillis »

frik wrote: post #86

Has Facebook switched to Mercurial? In one news it says so, in the next one read it has a ~50GB Git repo. If they really switched, it would be a good advertisement for Mercurial and its capabilities.

Seems like they’re in the process of switching; they have lots of code to migrate: https://code.facebook.com/posts/218678814984400/scaling-merc...

Re: What's New in Mercurial 3.0

#88

Post by colechristensen »

tomlu wrote: post #81
wtallis wrote: post #78

Earlier quoted context omitted.

Usually, you can build the game without them, up to the final packaging stage. Almost any game that is built on an engine can have all of the asset files swapped out without having to recompile anything, and as long as the file format and structure for assets is relatively stable there doesn't have to be a tight coupling between engine versions and asset versions except when doing QA and benchmarking. This is one of…

There usually are dependencies between the game and its assets, but sure, these dependencies can be managed. Historically I've dealt with the problem by keeping code and assets in separate repositories (using different version control systems). While it's worthwhile to do so in order to use git for code it really is a pain.

Exactly my initial point. It is really worthwhile to treat code and binary data differently, and the tools don't exist to make it not-so-painful.

To answer a couple of levels up, it's not bad practice because it isn't useful... there are many circumstances where having big binary blobs versioned and associated with code. It is bad practice because the tools are all written _for_ code and can get nasty when filled with binaries.

So there's a problem and a solution, but nobody seems to have put together the right magic yet.

Re: What's New in Mercurial 3.0

#89

Post by wirrbel »

Fice wrote: post #49
EGreg wrote: post #6

Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!

For me, the extreme popularity of GitHub is the No. 1 reason to avoid it as I do not want to contribute to the centralization of the Web. Also I like Fossil's [fossil-scm.org] approach of integrating wiki and bug tracker into DVCS, which allows projects to be less dependent on hosting services.

Fossil's user base has yet to reach a critical mass, mercurial and git are at least widely used and plugins, and services exist. I wonder if darcs will become a viable option again.

For git there is ticgit, which is a tracker that lives as a git branch.

Its definitely great to have several tools available and see a really productive evolution for good version control systems.

Re: What's New in Mercurial 3.0

#90

Post by wirrbel »

wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

Kind of sad how this post seemd to have resonated mostly for its reference to git, I intended (and failed) to point out my questions on mercurial. As a git user, I see one of the main features for mercurial: As it is in python, it can be used as a library. This should make tooling and cool developments so much easier for the average developer who is not a shell script person.
Post reply on HN