21–30 of 128 posts
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?
I am still disappointed that Git won.
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?
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…
As for using Python on .NET, that is what Iron Python is for.
Relevant quote: > Facebook is writing a Mercurial server in Rust. It will be distributed and > will support pluggable key-value stores for storage (meaning that we could > move hg.mozilla.org to be backed by Amazon S3 or some such). The primary > author also has aspirations for supporting the Git wire protocol on the > server and enabling sub-directories to be git cloned independently of a > large repo. This means yo…
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…
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…
I haven't worked on a monorepo, but I will say that Facebook _does_ use at least some of these tools, apparently: enough so that they created a whole replacement for the npm client, yarn. From talking to some companies that use monorepos that want to use Rust, they _do_ use these kinds of tools, but want support for it in the tool. Firefox, for example, is pretty much a monorepo, and we built tooling in Cargo to help…
I can definitely see an "app" (Firefox) as a monorepo but not giant web companies (particularly with the surge of microservices).
BTW Cargo is fantastic (and I'm fairly picky on package management / build tools).
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…
An example of utility of monorepos is things like automation--if you change, for example, how you publish packages, and you need to maintain multiple stable branches, it is immensely useful to keep the automation steps in the same repository as code. If you don't, your automation repository then looks like
if version 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…
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 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 going through a different layer).
Separate repositories would be enforcing it to a greater extent. But like I said earlier I suppose I could see it the other way (ie visibility and thus prevention).
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…
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.
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.
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 a tightly coupled C API might crash your application, though you can isolate the C API consumer in a supervised and automatically restarted server you talk to with messages, so that's the more flexible API to have.
The Rust rewrite of parts of Mercurial by Facebook is a no-brainer and given the possibility of GC-less C API in Rust, I wouldn't be surprised if a built-in-Rust C API for Mercurial were to follow. I don't like Rust when compared to high-level languages, but it's a viable C replacement with compile-time exclusion of certain bug classes, so I can get behind such a project. That said, the soundness bugs reported on github are worrisome, so I wouldn't trust Rust's checker to be correct or exhaustive, just yet. It's still a step up from C, that's undeniable.
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…
Because it's a pain in the ass and a monorepo means you don't have to deal with that crap for internal code. It's especially important for refactorings or API changes where you can atomically perform a change at once rather than have to wait for the changes to trickle down across hundreds of repositories over days or weeks.
> potential coupling that can happen with a gigantic code base
The coupling is a feature not a bug. Decoupling is a mean not an end, and it has costs. If you don't need it you'd rather not pay it. Same as generic collections, if you don't need them there's nothing wrong with specific ones, quite the opposite.