71–80 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?
If you have a ton of files inside of one gigantic repo, the work facebook is doing on mercurial might help you out. If you live in a saner world though, you'll probably benefit more from git's superior cli & tooling
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).
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).
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
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 biggest technical difference is the mostly immutable history, which is a feature or a drawback depending on who you talk to. More subjectively, most people I've chatted to about it seem to find Mercurial's interface much easier to grok / pick up as a new user than Git's (which is somewhat notorious for its quirks). There are other differences, but these stand out to me. That said, I use Git because adoption + com…
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…
Maybe Docker is the solution. Your "working state" is now in an image (maybe a Docker file that checks out particular revisions of different repos), so putting everything into one giant VC repo is not necessary. A versioned Dockerfile that says "this is how we built SystemX at version 1.5" is much better than doing it in Git, as it also covers how the underlying server was built, while a giant git repo might have eve…
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…
Seems kinda backwards to me, why not project portions of a monorepo to behave like individual repositories? That way you get atomic commits too.
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.
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. And all of these can be scripted.
Earlier quoted context omitted.
This post is about Mercurial with which i'm not familiar, but in Git you can checkout a subtree since version 1.7[1]. It's commonly called "sparse checkout". [1] http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s...
But you still need to clone the whole thing. Sparse clones are theoretically possible, but aren't implemented AFAIK.
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.
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…