Earlier quoted context omitted.
In what way? Have you looked at bookmarks?
I have. I'm wondering if they use bookmarks or named branches, and what strategies they've arrived at to work with either.
I'm pretty sure they're using a bookmarks workflow.
Scaling Mercurial at Facebook
81–90 of 245 posts
Re: Scaling Mercurial at Facebook
#82> We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Pray tell?
I know nothing of the code Facebook is hosting, but one fairly obvious general benefit of having things in a single repository is that you can use relative paths to link dependent projects, like if you have a directory structure such as: libs libs/mylib apps apps/myapp then myapp can reference library mylib via ../../libs/mylib If all of these things are in separate repositories, all bets are off about how their path…
You can still have the benefits of relative links without a single repo if you create a dir at the root level.
For example, you can have a /facebook/ dir on every machine with the source, and all your subprojects can assume they are working off that, ie:
include /facebook/somemodule
Re: Scaling Mercurial at Facebook
#83Earlier quoted context omitted.
I worked at Google (in a team using Perforce) and now work at a different company that uses multiple interdependent projects using Maven. Using a single monolithic codebase along with a build tool that statically builds everything at trunk has its advantages: * You immediately get improvements from upstream projects without having to get them manually. * You can unambiguously answer the question, What code am I using…
> * You immediately get improvements from upstream projects without having to get them manually. You also immediately get regressions. Not trying to be dismissive, but we fundamentally have different software philosophies if you think this point (which is the essence of most of your points) is a good thing that should be encouraged.
Test better.
Re: Scaling Mercurial at Facebook
#84Earlier quoted context omitted.
Does the standard branch workflow still expect you to have a separate repository and directory per branch? I don't care about plugins, here; if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. Likewise, does the standard workflow still intentionally make it painful to rearrange changes in your local repository to construct a series of patches?…
> Does the standard branch workflow still expect you to have a separate repository and directory per branch? You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo). > I don't care about plugins That's stupid,…
Furthermore, he's probably confusing mercurial with something that don't even exist
bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem
(I just wished that git people actually knew how do other tools work... but, alas! Now it's too late for underdogs like bazaar or darcs to catch up)
Re: Scaling Mercurial at Facebook
#85Earlier quoted context omitted.
That is certain. If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. The problem is "how do you grow even further ?" There isn't a perfect solution to that (yet), but I think the only existing workable (although absolutely imperfect) solution is splitting your codebase into many small repos. Thankfully very few companies need to worry about this prob…
> If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. that is the problem - single logical repo in Perforce/Mercurial does mean single physical repo. Which obviously causes issues at very large scale. Even at normal enterprise scale :) Git solves it through kind of distributed scaling where many operations can be performed on local physical repos wit…
Git doesn't solve the issue, it suffers from it, that's the point. And as others pointed out already, mercurial is a DVCS. It just isn't as shitty as git, that's all.
Re: Scaling Mercurial at Facebook
#86Earlier quoted context omitted.
>My suspicion is that open source projects tend towards Git because of GitHub but I think a lot of companies who don't have the option of external code hosting lean towards Mercurial. GitHub is a consequence not the cause (ponder for a moment why there is no MercurialHub...) It is about ability to choose best source control tool for multi-versioned distributed concurrent development. Open source devs have such choice…
There is a well used "MercurialHub", it's called BitBucket: https://bitbucket.org/ It supports Git now as well, but it was only for Mercurial use when it started.
I could have sworn bitbucket was an SVN host to start with, then patched in mercurial support and then git support later.
Re: Scaling Mercurial at Facebook
#87Earlier quoted context omitted.
Mercurial is a DVCS, just like git. It has no concept of a central server.
>Mercurial is a DVCS my bad. 5+ years since i worked with Mercurial. Digging deep into painful memories, my Mercurial PTSD from that time is absence of in-repo branching - need to clone which is a killer for very large repo we had and no partial commits - again a killer aggravated by the above mentioned absence of in-repo branches. Both issues made working with large repo unreasonably and unnecessary hard.
hg certainly has had branches since 2008 at least.
What do you mean by partial commit? I can guess but I would rather know. :-)
Re: Scaling Mercurial at Facebook
#88Earlier quoted context omitted.
> * You immediately get improvements from upstream projects without having to get them manually. You also immediately get regressions. Not trying to be dismissive, but we fundamentally have different software philosophies if you think this point (which is the essence of most of your points) is a good thing that should be encouraged.
Test better.
Nice passive aggressive comment. Should try enlightening the commenter instead of berating them.
Re: Scaling Mercurial at Facebook
#89Earlier quoted context omitted.
> How do you do that without loosing the history of those files? I don't know how you did it, but I found `git subtree split` to be an easy solution for extracting a directory into its own repo: https://github.com/git/git/blob/master/contrib/subtree/git-s... (It's a shame git-subtree it's still in contrib/, should really be enabled by default. It can also work as git-submodule replacement in some cases, by the way.)
Even if it isn't neatly in it's own tree, you can get away with rewriting commits and some tree objects. It's more complicated, but it can be made to work. Either isn't as nice as `p4 move ...` though.
But this isn't something that needs to be nice. Files moving between libraries should be rare in well designed libraries, and splitting a subtree out of git is easy enough for when the need does occur.
Keeping a giant repository on the other hand makes it very easy to do stupid things and end up with tightly coupled code. You don't want that to be the path of least resistance.
Re: Scaling Mercurial at Facebook
#90Earlier quoted context omitted.
> If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. that is the problem - single logical repo in Perforce/Mercurial does mean single physical repo. Which obviously causes issues at very large scale. Even at normal enterprise scale :) Git solves it through kind of distributed scaling where many operations can be performed on local physical repos wit…
Git doesn't solve the issue, it suffers from it, that's the point. And as others pointed out already, mercurial is a DVCS. It just isn't as shitty as git, that's all.
Mercurial itself runs into issues way before git does, it's just that Facebook has essentially gutted a bunch of things out Mercurial in order to make the resulting thing fast (punting on things like computing status, downloading diffs, etc).