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

41–50 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#41

Post by ngoldbaum »

shoover wrote: post #39
pjmlp wrote: post #21

Earlier quoted context omitted.

A sane distributed source control system implemented in Python. I am still disappointed that Git won.

Agreed. And yet it is encouraging to see the continued investment and upstream engagement by Facebook and Mozilla. (I knew Facebook and Mozilla were heavily invested; I'm not sure what Google's involvement is since code.google.com was abandoned.) Things could get more competitive in terms of global mindshare if more Facebook engineers (some of whom the OP mentioned have forgotten how to use git) start speaking out in…

Google is working on adding mercurial as a frontend for their repository management system (Piper) and development environment (CitC).

Re: Mercurial 4.0 Sprint Notes

#42

Post by adrianratnapala »

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…

Regarding performance: these mono-repo tools work differently and are optimised for their workload.

Regarding why the hell you would do it: In a corporate setting you tend to throw all kinds of st into your repo. In my workplace that includes, network configurations, 200 MB binary tools, usernames (and who knows, passwords too probably).

We do this because we want all the different things, including external dependencies and "ops stuff" to be syncronised. That would be totally insane in the open source world where you are releasing to the public -- but it seems corporations can make it work internally.

Re: Mercurial 4.0 Sprint Notes

#43

Post by tonfa »

cmrdporcupine wrote: post #38
pierrebai wrote: post #37

Earlier quoted context omitted.

Then maybe you can answer a few questions: - Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? - What about release branches? If you need to intergrate a bug-fix in a sub-system, the magic mono-repo now means merging a fix is harder as it may…

I am not sure how much of that I can answer in detail, sorry. But yes we have working strategies for dealing with both situations.

http://m.cacm.acm.org/magazines/2016/7/204032-why-google-sto... has a lot of answers (was published last summer).

Re: Mercurial 4.0 Sprint Notes

#44

Post by z3t4 »

pierrebai wrote: post #37
cmrdporcupine wrote: post #28

Earlier quoted context omitted.

Been at Google for coming up 5 years and I don't think I'm giving away any secrets when I say don't recall there being any performance issues with the mono repository. And coupling is what is explicitly being sought, not rejected. The whole point is to build everything off head, keep head sane at all times, and avoid version dependency hell.

Then maybe you can answer a few questions: - Do you have zero external dependencies on 3rd party library not own by Google? These must still be managed anyway? How do you deal with project X is not ready to move to external library version N but project Y needs version N? - What about release branches? If you need to intergrate a bug-fix in a sub-system, the magic mono-repo now means merging a fix is harder as it may…

I think its insane not to have dependencies and third party code in your scm. Although it seems facebook plan to move those to a package manager due to performance problems and libs touching ten thousand files in a path release.

Re: Mercurial 4.0 Sprint Notes

#45

Post by pohl »

steveklabnik wrote: post #17
Stratoscope wrote: post #13

Earlier quoted context omitted.

A suggestion if I may... Don't use monospaced formatting (two-space prefix) as a way to put a '>' on every line of a long quote, as it becomes unreadable on mobile. One '>' at the beginning of each paragraph is good enough (with blank lines to separate paragraphs), or italics are fine too. Here's a copy that should be readable on any device: > Facebook is writing a Mercurial server in Rust. It will be distributed and…

This is offtopic so I'll leave it to just this one reply, but thanks! Lack of quoting in HN's markdown is the only part I have actual frustration with it; I usually use the two-space + wrap format because it makes it much more clear that it's a quote; I find your version hard to tell. But that said, I checked on my phone, and I see what you're saying about mobile. Ugh.

HN markdown does support italics, so italicizing entire paragraphs is a viable alternative to differentiate what you're quoting from your own comments. I've seen folks do it now & then.

Re: Mercurial 4.0 Sprint Notes

#46

Post by geodel »

pjmlp wrote: post #21
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?

A sane distributed source control system implemented in Python. I am still disappointed that Git won.

Also C won, Unix won, Android won. Seems technical subpar options are better business options.

Re: Mercurial 4.0 Sprint Notes

#47

Post by pjmlp »

geodel wrote: post #46
pjmlp wrote: post #21

Earlier quoted context omitted.

A sane distributed source control system implemented in Python. I am still disappointed that Git won.

Also C won, Unix won, Android won. Seems technical subpar options are better business options.

You forgot JavaScript and PHP.

Re: Mercurial 4.0 Sprint Notes

#48

Post by hinkley »

avar wrote: post #31
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 someone who works at another company with a big monorepo, briefly: * Ability to change an API and all its users at the same time. * Circular dependencies become a non-issue in a lot of cases where the would be if you vendor your dependencies. * Even if you vendor your dependencies hunting for bugs is a lot easier, your bisect of a bug in a library will just come down the commit that upgraded it from 1.0 to 2.0 wit…

The big thing I miss about Subversion is that you could check out one subtree. On the biggest SVN project I worked on, we built 5 binaries from the same code tree, but only the leads and a couple of senior devs that worked on crosscutting concerns (ie, the people who would do the mass edits you mention) had the entire tree checked out. Everyone else had just the one or two modules they were working on.

The second biggest, we used just enough of a module system to enforce modularity by having a single code repo but separate compilation units. Your circular dependencies between subprojects would show up at compile time (or at least, on a clean build, as our CI machine did). Stopped a lot of obscure runtime issues and made people think about what they were trying to do.

Re: Mercurial 4.0 Sprint Notes

#49

Post by avar »

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…

The .git file format has also changed multiple times, packed refs, multiple pack file formats etc. There's even WIP ref backends now which store the whole thing in some embedded database format.

Re: Mercurial 4.0 Sprint Notes

#50

Post by jordigh »

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…

This is a FAQ:

http://danluu.com/monorepo/

Post reply on HN