91–100 of 128 posts
Earlier quoted context omitted.
But you still need to clone the whole thing. Sparse clones are theoretically possible, but aren't implemented AFAIK.
You can do a shallow clone; see the --depth option.
Earlier quoted context omitted.
May be I am not understanding the problem correctly, but I wonder why you couldn't use separate repos, and build a script to record the current commit hash of every other repo when you make a commit in any one of the repo. So every commit in every repo has a map that maps the repo path to a commit hash. You can use this info to sync the versions of other repos when you update/checkout a version in any of the repos. A…
Why would you resort to a set of hacky scripts that everyone who wants to use the repository must follow when you can just let the VCS itself manage everything for you?
Because then you can keep the repos separated. Not saying that you should. But if this is the only problem that forces you to use a mono repo, then I am just asking if that problem can be solved in this manner?
>hacky scripts that everyone who wants to use the repository must follow when you can just let the VCS itself manage everything for you?..
What hacky scripts? Do you think they (google, facebook etc) don't have enough resources to build a 'non hacky' script for what ever they needs done?
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…
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…
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
It's possible that your slow pulls were due to the initial storage format being inefficient for very branchy repositories. I've documented migrating to generaldelta to solve this here: https://book.mercurial-scm.org/read/scaling.html#scaling-rep...
Additionally, using the 'clonebundles' feature, it's possible to speed up your initial clone by a huge amount (making it way faster than non-clonebundles Mercurial or Git): https://book.mercurial-scm.org/read/scaling.html#improving-s...
Of course, this is too late for you, I guess...
That was a busy meeting and the developer mailing list is very busy. It's great to see continued investment from so many interested parties. Judging by the notes in the wiki [1], however, the purveyors of my preferred server, Kiln, are not so engaged lately: > Available hosting solutions: Bitbucket, Kallithea (self-hosted), Kiln (still exists?) I believe it is maintained and even if not maintained would continue to w…
What's you best KILN feature ? I wonder if we can adopt it at RhodeCode
Bitbuckets code review implementation doesn't handle big changes gracefully though, so I primarily inspect the changes in Beyond Compare.
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…
Or you can have your tooling use the convenient built-in versioning provided by the VCS. It's not called a "version control system" for nothing.
> 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.
This happens regardless of whether the codebase is organized as a monorepo or not. I've been subjected to monorepos at my previous and current employers, and we run into difficulties with this all the time. At least once a quarter, I get an e-mail from someone telling me that they updated such-and-such, and now the build fails in one of my projects. So I have to sit there and figure out wth they changed, why it's causing my code to fail the build, and how to fix it. Only once was the problem actually in my code (my Makefile, actually, which failed to bind some variable that was expected by the build system but wasn't documented anywhere, and of course the build system spits out a worthless error message, but I digress).
> You end up with a complicated dependency headache which hurts productivity.
Again, monorepos aren't immune from this, nor do polyrepos inherently suffer from it.
> 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.
There is literally nothing preventing this from being doable with a polyrepo. In the case of updates, you may need to have the updated repos checked out, but it's not like you can only ever have one repo checked out at a time.
> 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.
I've never worked anywhere on any project that disallowed commits that didn't pass the tests. It's typically been up to the committer to ensure that what they commit is acceptable. Furthermore, while my employers thus far have all been customers of AccuRev or Perforce (whose only real feature beyond what Subversion offers is that they cost lots of money), and have not personally had the pleasure of working with a DVCS at my day job, this workflow of "allow only test-passing commits" is wholly contrary to the "many small commits in quick succession" workflow afforded by DVCSs, which I contend is one of the biggest productivity boosts afforded by DVCSs (along with cheap branches and network unnecessity) and one of their main draws. And even so, it's still rather easy to maintain a sane and working HEAD with a DVCS (thanks to the cheap branches if nothing else).
If you find that you can't do anything you've listed here without a monorepo, that's a tooling issue rather than an organizational one. Frankly, I've never seen a large monorepo I felt was justified. Every single one was just baggage held over from a time long past when a single repo still made sense for the codebase.
Earlier quoted context omitted.
Where were and are you hosting it? SSH vs HTTPS? Client? OS? Any hooks?
We were hosting both on an ESX VM and clones / pulls were done via SSH. OS was FreeBSD on both ends. Hookless. Part of the reason for the move is that we wanted to take advantage of the corp-wide infrastructure of an Atlassian stash server hosted in the cloud and professionally maintained, so as to get away from maintaining our own repo. But the speeds I quote above were for the initial phase of the conversion, when…
What about speed? Our team just moved from hg to git for an enormous project that has ~25 years of history (CVS -> SVN -> hg|git). The biggest improvement to my daily life is that a git pull takes seconds, while an hg pull takes minutes (or even large fractions of hours when I've spent a week or two away from work).
They always measure Mercurial pull performance using a load tests. For example between 4.2.X and 4.4.X version of our software we went form 1.8s to 1.4s average time for a pull to happen under load.
We only do this via HTTP since this can be really optimized for speed. So having to take minutes sounds like some backend problems like overloaded server, not enough workers to handle connection etc.