231–240 of 245 posts
Earlier quoted context omitted.
No, git runs into issues before mercurial does. Just saying the opposite of reality doesn't make it so.
Did you even read the post? Stock git is significantly faster than stock mercurial, it's only after they hack it up that they make it faster.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
Ideally, to make a breaking API change, you change the function and all the references within a single commit. Since this repository is only used for statically compiled programs, there is no need to keep the old API anymore. For protocols and file formats, Google universally uses protocol buffers with many optional fields. The protocol buffer library’s default is that when you read a protocol buffer, modify it, and…
Useful flexibility from protocol buffers there. To me it seems like having to change all references for a breaking API change could be a debilitating amount of work in some cases. Do you then make your breaking change to a branch and lobby for other teams to catch up before merging to the main branch? What about situations where you have a legion of stable legacy applications that may not be worth updating for any re…
If an application is still being used, it is always stored in the source tree, where the unit tests are automatically run. You do still have choices to lock its API or file formats: you can consider the API deprecated and tell everyone to use the new V2 API, or you can move the old program into a branch (but still in the source tree that everyone can see). But you want to branch as little as possible; large unmaintained branches quickly become unmaintainable.
Earlier quoted context omitted.
I have seen presentations mentioning google development done as a single monolothic repository http://www.infoq.com/presentations/Development-at-Google
This monolithic repo isn't a git repo.
Earlier quoted context omitted.
This question is actually really complicated to answer. The short answer is that we run perforce. The long answer is that we run perforce with a bunch of caching servers and custom stuff in front of it and some special client wrappers. In fact there is more than one client wrapper. One of them uses git to manage a local thin client of the relevant section of the repo and sends the changes to perforce. This is the one…
Interesting, has Google made the client parts open source? It would be great if someone used that to write a high performance git server. Could they?
We actually have an open source tool that allows you carve off parts of your Perforce server as Git repos. The repos can overlap in Perforce allowing you to share code seamlessly between different Git repos. You can generate new repos from existing code easily and can even generate shallow git repos that are usage for development.
Details are at: http://www.perforce.com/product/components/git-fusion
I'm happy to answer questions here or on Twitter: @p4mataway
Earlier quoted context omitted.
No, but you do need a single repo if you want to make the API change and update all the dependencies in one fell swoop.
Does this matter that much if you version everything? Commit in library -> successful library build, failed client build. Commit in client -> successful library build, successful client build. In both situations you don't really care about the intermediary broken build - you still have the previous library/client versions and can use those. Once everything is committed & fixed you have the new versions and you can up…
Earlier quoted context omitted.
I suspect many of us use Git because it was made by Linus Torvalds ( I think everyone agrees that he is a great developer) and is used in the Linux kernel. If it can handle that, then you can be pretty sure it will handle whatever you throw at it (unless you are Facebook, it seems). Add Github to that mix and you can see why so many developers sleep like babies at night. Of course it's not rigorous, but the choice is…
The linux kernel is much smaller than the entire codebase of Facebook.
Earlier quoted context omitted.
We eat our own dog food, most teams have moved over to TFS by now. I don't know about the larger orgs (Windows, Office) but for smaller groups TFS is how it is. MS doesn't have a unified build environment, every team generally does their own thing. It has its pluses and minuses. Shared code would occasionally be useful at Microsoft, but not as often as you'd think. Generally when relying on another team's code, it is…
> We eat our own dog food. Except for that whole ".NET framework" thing.
All web sites are of course written in ASP.NET. Giant portions of the Xbox Live service are written in .NET. Heck lots of tools and utilities are also .NET based.
Is someone going to rewrite IE in C#? Not likely, that isn't what C# is for.
Earlier quoted context omitted.
> We eat our own dog food. Except for that whole ".NET framework" thing.
I'd say 70% of the projects I know about in MS use .NET. All web sites are of course written in ASP.NET. Giant portions of the Xbox Live service are written in .NET. Heck lots of tools and utilities are also .NET based. Is someone going to rewrite IE in C#? Not likely, that isn't what C# is for.