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

31–40 of 128 posts

Re: Mercurial 4.0 Sprint Notes

#31

Post by avar »

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 without a monorepo, with a monorepo you can bisect anything down to a specific commit.

* Code discoverability / mass edits are a lot easier, and integrate seamlessly into a lot more tools than if you need to manage multiple checkouts etc.

Re: Mercurial 4.0 Sprint Notes

#32

Post by the_duke »

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 update those automatically with tooling, or manually. You can also monitor where and how a piece of code is used across the company, etc.

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.

Of course there are lot's of drawbacks as well.

But Google and FB seem to have concluded that this is the better approach for them.

Re: Mercurial 4.0 Sprint Notes

#33

Post by barkingcat »

agentgt wrote: post #27
gcp wrote: post #24

Earlier quoted context omitted.

OSSing certain parts is certainly an issue, but what do you mean with "potential coupling" being an issue? That's exactly the advantage, right?

I suppose you could make the argument the other way but my thoughts are that by having the code all together it maybe confusing what is public API (ie interfaces / contracts) and what is not. I know personally that I have had to move components into separate projects (not necessarily repositories but compile units) to avoid developers from accessing things they shouldn't (e.g. access the database directly instead of…

I don't use version control systems to any extent but it seems like your developer problem is an issue of team-coherence and code review, and not a matter that your vcs should/need to enforce.

Even in a distributed team like linux kernel development, code maintainers have the ability to say "this is how we (as core maintainers) want you to access certain data structure. If we catch you doing anything else illegally, your code won't be accepted, and we will keep rejecting your code until you adhere to our coding style and api design."

Re: Mercurial 4.0 Sprint Notes

#34

Post by denfromufa »

pjmlp wrote: post #22
cm3 wrote: post #15

Earlier quoted context omitted.

The possibility of extending the Mercurial core with a well-defined API is one major reason. In fact, most interesting features are extensions, bundled with Mercurial, and after several releases and experience, the functionality usually gets integrated into Mercurial proper (most often than not still as an extension). This is, unfortunately not an C API but Python, but it's still an advantage Mercurial has for now. G…

Actually the fact that Mercurial uses Python is what made it quite usable on Windows from the get go, before Microsoft and others bothered to step up and improve the experience. As for using Python on .NET, that is what Iron Python is for.

Python for .NET (pythonnet) allows to bridge CPython and .NET/Mono runtimes.

Re: Mercurial 4.0 Sprint Notes

#35

Post by pjmlp »

cm3 wrote: post #29
pjmlp wrote: post #22

Earlier quoted context omitted.

Actually the fact that Mercurial uses Python is what made it quite usable on Windows from the get go, before Microsoft and others bothered to step up and improve the experience. As for using Python on .NET, that is what Iron Python is for.

Of course Python as an abstraction layer made it more readily available on Windows and allowed allocation of developer resources to hgtk, including a Windows Explorer extension. Still, despite its flaws, C is the common layer we have to expose an API that you want to be consumed everywhere. That, or a message passing interface with a client/server architecture. A client/server design may lead to zombie servers, while…

Well, on Windows we also have COM, but I get your point.

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.

Re: Mercurial 4.0 Sprint Notes

#36

Post by agentgt »

barkingcat wrote: post #33
agentgt wrote: post #27

Earlier quoted context omitted.

I suppose you could make the argument the other way but my thoughts are that by having the code all together it maybe confusing what is public API (ie interfaces / contracts) and what is not. I know personally that I have had to move components into separate projects (not necessarily repositories but compile units) to avoid developers from accessing things they shouldn't (e.g. access the database directly instead of…

I don't use version control systems to any extent but it seems like your developer problem is an issue of team-coherence and code review, and not a matter that your vcs should/need to enforce. Even in a distributed team like linux kernel development, code maintainers have the ability to say "this is how we (as core maintainers) want you to access certain data structure. If we catch you doing anything else illegally,…

While I appreciate the "code review should be improved" it is fairly easy to accidentally import something you should not have in many IDEs (the merge the class path) as well as other accidents. These issues along with many others including code formatting can be automated.

Separate projects allow less namespace collision accidents.

You could achieve all of this with monorepo but requires proper tooling.

Re: Mercurial 4.0 Sprint Notes

#37

Post by pierrebai »

cmrdporcupine wrote: post #28
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…

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 depend on other unrelated changes all over teh repo? The laissez-faire attitude of not having to care about details in HEAD would seem to bite back in release branches.

Re: Mercurial 4.0 Sprint Notes

#38

Post by cmrdporcupine »

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 am not sure how much of that I can answer in detail, sorry. But yes we have working strategies for dealing with both situations.

Re: Mercurial 4.0 Sprint Notes

#39

Post by shoover »

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.

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 favor of Mercurial.

Re: Mercurial 4.0 Sprint Notes

#40

Post by cyphar »

pjmlp wrote: post #35
cm3 wrote: post #29

Earlier quoted context omitted.

Of course Python as an abstraction layer made it more readily available on Windows and allowed allocation of developer resources to hgtk, including a Windows Explorer extension. Still, despite its flaws, C is the common layer we have to expose an API that you want to be consumed everywhere. That, or a message passing interface with a client/server architecture. A client/server design may lead to zombie servers, while…

Well, on Windows we also have COM, but I get your point. 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.

> 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 also extensively tested with dummy failures and so on). So a rewrite in a safer language would benefit nobody (and would just be a huge time sink).

Post reply on HN