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

111–118 of 118 posts

Re: What's New in Mercurial 3.0

#111

Post by ezquerra »

__david__ wrote: post #67
jordigh wrote: post #47

Earlier quoted context omitted.

>Most of my history rewriting is done locally before I've ever pushed That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?

Perhaps, but I think it's more fundamental than that. Like I said earlier, I don't save after ever character or word typed into a file, and I don't even commit changes until I think they might be ready. I don't push until it works (for some definition of "works" depending on how lazy I am and what project it is). There are all these different levels of "saveyness" and the lower levels are just not as interesting. In…

When you enable mercurial's evolve, history rewriting operations are no longer destructive. Mercurial's evolve creates a sort of repository "meta history" by saving every revision before you modify it (e.g. by using amend). It makes those saved, old versions "obsolete" and it "hides" them (so that they won't show on your DAG when you do "hg log", for example, unless you use the --hidden flag). Evolve also keeps track of the relationship between obsolete revisions and their "successors". That is, it will know whether a certain revision in your DAG is the result of amending one revision, or perhaps of folding several revisions into one, or splitting one revision in two or perhaps just removing a revision from the DAG (this is what I called repository meta history above).

Those hidden, obsolete revisions are not shown on your DAG and they are generally not pushed nor pulled. In most respects they behave as if they were not even there. It is only when you need them that you can show them or go back to them (by using the --hidden flag of some of mercurial's command such as hg log or hg update). This gives you a nice safety net (since rewriting history is no longer a destructive operation) that you can use _if you want_. It also makes it possible to rewrite revisions that you have already shared with other users (since when you push a successor revision you also push the list of revisions that it is the successor of).

I think evolve is a significant step forward on the DVCS paradigm as it enables safe, distributed, collaborative history rewriting. This is something that, AFAIK, was not possible up until now.

Re: What's New in Mercurial 3.0

#112

Post by watchdogtimer »

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's also Trac:

http://trac.edgewall.org

Re: What's New in Mercurial 3.0

#113

Post by tonfa »

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.

FYI Mercurial has time-based releases. So 3.0 doesn't mean anything special (it's just the next feature release after 2.9).

http://mercurial.selenic.com/wiki/TimeBasedReleasePlan

Re: What's New in Mercurial 3.0

#114

Post by colechristensen »

Locke1689 wrote: post #93
colechristensen wrote: post #56

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. I'd like to see a second class of files which are only checksummed (or timestamped) on 'status', 'diff', 'add' and then binary-diffed on commit for possible compression (or perhaps deduped with checksums of blocks) with features like 'git/hg binary-add somefile.jar' to…

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. It's only a bad practice because our tools don't support it properly. There seems no reasonable argument that there is some predefined size limit that all assets in version control must, by natural law, fall under. The criteria I have for version controlled assets is t…

>It's only a bad practice because our tools don't support it properly.

Yes, exactly.

Re: What's New in Mercurial 3.0

#115

Post by ygra »

tomlu wrote: post #80
sherlockmao wrote: post #70

Earlier quoted context omitted.

Facebook's hgwatchman and remotefilelog extensions; largefiles

Those are interesting, and git has some similar large file extensions too. However during some years of experimentation I have become convinced that these features have to be part of core or they will always be second-rate citizens and not work well in practice.

Hg is modular and lots of more advanced features are shipped as extensions. Just because they are disabled by default doesn't mean that they are unsupported or are second-rate citizens.

Re: What's New in Mercurial 3.0

#116

Post by __david__ »

masklinn wrote: post #104
__david__ wrote: post #101

Earlier quoted context omitted.

You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels. Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.

> Git is like driving a manual transmission. Git is nothing like driving manual. > In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "g…

> Different gears are for "go faster" and "go slower", and the clutch is for "change gear".

Sorry, that's exactly what I meant by "the different gears work in general". You need to understand that underlying model before you can make it work, even if it's only intuitive, and not cerebral.

> the clutch is for "change gear"

That, and it's also "don't stall when I stop".

I think most people understand that it disconnects the engine. I don't think that's as crazy a leap as "understanding the details of how a gearbox works" (which I don't even know, since I've never looked in one).

Anyway, I maintain that my analogy is apt.

Re: What's New in Mercurial 3.0

#117

Post by masklinn »

__david__ wrote: post #116
masklinn wrote: post #104

Earlier quoted context omitted.

> Git is like driving a manual transmission. Git is nothing like driving manual. > In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "g…

> Different gears are for "go faster" and "go slower", and the clutch is for "change gear". Sorry, that's exactly what I meant by "the different gears work in general". You need to understand that underlying model before you can make it work, even if it's only intuitive, and not cerebral. > the clutch is for "change gear" That, and it's also "don't stall when I stop". I think most people understand that it disconnect…

> You need to understand that underlying model before you can make it work

No, you only need to understand what the final effect is. The vast majority of drivers neither understand nor care that gearbox speeds change the conversion ratio between the engine's rotating speed and the axle's, if you did and had to gear speeds would be labelled by their conversion ratio not 1-6 (and then you'd have to include the axle's conversion ratio in the mix). And I don't doubt that a Git-based gearbox would do exactly that, and that going in reverse would require either using an inverter or would require using a completely separate reverse transmission.

> Anyway, I maintain that my analogy is apt.

And I maintain that it is not.

Re: What's New in Mercurial 3.0

#118

Post by novaleaf »

mrtngslr wrote: post #105
novaleaf wrote: post #75

Earlier quoted context omitted.

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.

Largefiles are being used for production in game companies and we have not gotten reports about corruption.

i used large files with game assets via tortoise hg. if there's a network timeout, corruption of the largefiles occurs ..

what client do you use?

Post reply on HN