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

Mercurial 4.0 Sprint Notes

groups.google.com

Post reply on HN
Print view View original

101–110 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#101

Post by Mathiasdm »

bedros wrote: post #94
kyrra wrote: post #16

Earlier quoted context omitted.

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more compl…

narrowhg looks like a good replacement for subrepo, thanks for the tip

Keep in mind that narrowhg is extremely experimental!

Re: Mercurial 4.0 Sprint Notes

#102

Post by ksec »

So is this a comeback of Mercurial?

I know Subversion is pretty much dead, Mercurial was sidelined and Git seems to have conquered the world. The only thing I think would shake things up a little would be Perforce going Open Source. But i dont see that happening as they seems to be very comfortable in their niche.

Re: Mercurial 4.0 Sprint Notes

#103

Post by s_kilk »

kyrra wrote: post #16
the_duke wrote: post #6

I had no idea Google and FB were dabbling with Mercurial. I checked it out years ago, but pretty much settled on Git. What are the advantages?

1) The .git directory doesn't play nicely with mono-repos. Since all files are just hashed files that live in the .git dir, knowing which files in there are part of a subtree is hard. On the other side, Mercurial .hg dir uses a tree structure to track files, so you can do things like NarrowHG[0]. 2) As well, Git has multiple client implementation (like git, egit, jgit, etc...). Adding new features is a bit more compl…

Mercurial also has a proper plugin architecture, which means that new features can be developed in the wild as needs arise, and then either become widely used or rolled into the standard distribution.

Re: Mercurial 4.0 Sprint Notes

#104

Post by cyphar »

jjnoakes wrote: post #68
cyphar wrote: post #40

Earlier quoted context omitted.

> Going off topic, maybe someone will eventually do a SQLLite re-write as well and other critical projects to our modern stacks that still rely on C. SQLite does not need to be rewritten. It has the best and most comprehensive test suite in the history of software development -- I would go so far as to say that there are no implementation bugs in SQLite (every single branch in the code has been extensively tested and…

I'm not advocating one way or the other, but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent. Now it probably isn't worth the effort for a very well tested project like sqlite, but that doesn't validate the premise.

> but I will say that I don't believe 100% code coverage guarantees that you have no issues lurking that a safer language would prevent.

It's 100% branch coverage, with 100% fault coverage as well. If there is an "issue lurking that a safer language would prevent" I would honestly be shocked. SQLite is not a good project to mention rewriting, because it is an incredible technical acheivement in terms of how well tested it is.

Re: Mercurial 4.0 Sprint Notes

#105

Post by marcinkuzminski »

Bjartr wrote: post #59
marcinkuzminski wrote: post #14

Earlier quoted context omitted.

CTO of RhodeCode here. If you use phases (draft/secret/public) correctly it's really close to being mutable. For example all our devs forks are having non-publishing repositories since it's a private non-shared space. By keeping all commits as draft it's easy to do a rebase and then push new changed commits. While the main repo is publishing and once pushed commits are never mutable, also we keep a workflow that only…

Do you have or know of writeups describing this workflow in more detail? I'm interested in learning more.

Here's a blog post on how to use Bookmarks in Mercurial workflow using code-review. We back ported from one of the guys that works for us and described our workflow:

https://rhodecode.com/blog/120/mercurial-workflow-using-book...

Re: Mercurial 4.0 Sprint Notes

#106

Post by agentgt »

jahewson wrote: post #77
agentgt wrote: post #19

I know this is slightly tangental but I'm always a little shocked that Facebook (and I think Google to some extent) have massive mono repositories. The benefits of having one repository do not seem to be worth the serious performance issues as well as potential coupling that can happen with a gigantic code base as well also making much more difficult to OSS certain parts. e.g. why doesn't FB use dependency management…

> There are even plugins and shell scripts that will make Mercurial act like a mono repository for many small repositories Seems kinda backwards to me, why not project portions of a monorepo to behave like individual repositories? That way you get atomic commits too.

> Seems kinda backwards to me, why not project portions of a monorepo to behave like individual repositories? That way you get atomic commits too.

But on the other hand you now need custom scripts to filter out other projects that are completely irrelevant to you. Just the .hgtags file alone must be a 10k line nightmare... or maybe the big boys just don't deploy/release often. It is a lot more tooling than I think you might think.

Linux and Firefox having a monorepository is not the same as a whole company as big as google and facebook having a single repository for all of their projects.

I'm not even sure if these companies really are doing that. The use of monorepository could just mean a single place of storage but maybe they do allow a couple of trees (or maybe not).

Re: Mercurial 4.0 Sprint Notes

#107

Post by jjnoakes »

lucideer wrote: post #82
jjnoakes wrote: post #69

Earlier quoted context omitted.

Can you elaborate on what you mean by immutable history, and how git lacks it?

In git you can edit past commits and rebase, which completely destroys historical data and traces of the rebase. This can be very useful, e.g. for keeping a frequently-committed-to branch "clean" and informative by squashing commits, for removing accidentally committed sensitive credentials, etc. Mercurial, on the other hand, is architecturally set up in a way that considers the repo history to be a somewhat "sacred"…

I'm sorry, I still don't see the distinction. It sounds like in both systems the default is immutability, with commands to override that if necessary.

And by the way, doesn't git rebase not mutate history? I believe it creates a parallel history (and updates the branch and head refs to point to the new history) but the old history still exists in git's storage and can be recovered (until you GC your storage).

Re: Mercurial 4.0 Sprint Notes

#108

Post by agentgt »

jcranmer wrote: post #26
agentgt wrote: post #19

I know this is slightly tangental but I'm always a little shocked that Facebook (and I think Google to some extent) have massive mono repositories. The benefits of having one repository do not seem to be worth the serious performance issues as well as potential coupling that can happen with a gigantic code base as well also making much more difficult to OSS certain parts. e.g. why doesn't FB use dependency management…

Anyone who is old enough to remember the pain of VCSes like CVS and RCS will note that the number one feature touted to move to any other VCS is invariably "atomic changesets"--all the necessary changes to files are listed in a single changeset. Monorepos are nothing less than remembering the value of those atomic changesets. An example of utility of monorepos is things like automation--if you change, for example, ho…

If you do it right your automation steps are just another package dependency that is versioned (I know because this is how we do it). We have a single bash script that will auto update itself (think akin to home brew albeit in bash).

The only immensely dangerous thing that can happen is if you drop your package repository or change formats of the repository which rarely happens.

Re: Mercurial 4.0 Sprint Notes

#109

Post by agentgt »

amluto wrote: post #95
agentgt wrote: post #19

I know this is slightly tangental but I'm always a little shocked that Facebook (and I think Google to some extent) have massive mono repositories. The benefits of having one repository do not seem to be worth the serious performance issues as well as potential coupling that can happen with a gigantic code base as well also making much more difficult to OSS certain parts. e.g. why doesn't FB use dependency management…

As an open-source example, the Linux kernel is a mono repository. It makes refactoring easier, and it makes it much easier to drop support for old (or not so old) unused features.

The Linux Kernel and Firefox (mentioned earlier) are not really good examples. I would put those in a single repository as I would imagine most people would.

But a whole company as big as FB and Google using a single tree seems like an incoherent nightmare without proper (somewhat proprietary) tooling (filtering of logs, branches, tags, etc).

Re: Mercurial 4.0 Sprint Notes

#110

Post by agentgt »

the_duke wrote: post #32
agentgt wrote: post #19

I know this is slightly tangental but I'm always a little shocked that Facebook (and I think Google to some extent) have massive mono repositories. The benefits of having one repository do not seem to be worth the serious performance issues as well as potential coupling that can happen with a gigantic code base as well also making much more difficult to OSS certain parts. e.g. why doesn't FB use dependency management…

When you split your libraries into separate projects, you have to start versioning them. And every update to the code requires other teams to then update their library/app to use the new version, and apps depending on that dependency... you get my drift. You end up with a complicated dependency headache which hurts productivity. With a monorepo, you can statically identify all places where your library is used and up…

> You end up with a complicated dependency headache which hurts productivity.

>With a monorepo, you can statically identify all places where your library is used and update those automatically with tooling, or manually. You can also monitor where and how a piece of code is used across the company, etc.

Aka you have to figure out dependencies regardless of monorepo or not. Aka you need dependency management. Of course you could make the argument everyone has to use the latest greatest but you now have the possibility of changing one dependency and requiring an entire redeploy of the whole company.... I have seen what people do in these cases during desperate times... they copy the code and put it in their own project which sort of defeats the purpose and worse it is now not tracked (well I suppose if they have a good enough SCM comment it sort of is).

> If you then ensure that only commits get accepted that pass the relevant tests, you end up with a sane and working HEAD that's always up to date.

It depends on workflow. For some HEAD is what is actually deployed. If that is the case it is fairly difficult to achieve that goal with a giant monorepository if you have tons of teams doing microservices and deploying often.

Post reply on HN