Comments on: Perforce as the version control system at Google http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/ Version control, software configuration management (SCM) Thu, 21 Aug 2008 18:44:08 +0000 http://wordpress.org/?v=2.0.11 by: version_control_system = { “Google” => “Perforce” } :: Fat Penguin http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-140 Sat, 10 Mar 2007 07:14:05 +0000 http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-140 [...] I knew Google was using Perforce for awhile. Today I ran into this blog entry and what piqued my interest was the setup and the way Google uses Perforce. Check out that page for details. I also highly recommend checking out the presentation slide on Performance and Database Locking at Large Perforce Sites. Moreover, Google has a custom code rewiew application called Mondrian, written in Django. Mondrian is a web-based code review system built on top of a Perforce and BigTable backend with a Python-powered front-end. [...] […] I knew Google was using Perforce for awhile. Today I ran into this blog entry and what piqued my interest was the setup and the way Google uses Perforce. Check out that page for details. I also highly recommend checking out the presentation slide on Performance and Database Locking at Large Perforce Sites. Moreover, Google has a custom code rewiew application called Mondrian, written in Django. Mondrian is a web-based code review system built on top of a Perforce and BigTable backend with a Python-powered front-end. […]

]]> by: squadette http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-5 Mon, 11 Dec 2006 21:18:22 +0000 http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-5 pablo, I've never heard of "branch per developer" pattern, and I cannot really understand its usefulness. I've found several interesting links to blog while researching the issue, thanks! Also, I'll take a look at what PlasticSCM does. pablo,

I’ve never heard of “branch per developer” pattern, and I cannot really understand its usefulness.

I’ve found several interesting links to blog while researching the issue, thanks!

Also, I’ll take a look at what PlasticSCM does.

]]> by: psluaces http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-4 Mon, 11 Dec 2006 06:37:28 +0000 http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-4 Well, what I wanted to say was that branches are useful not only to split development, but also to coordinate teams. In the case you're describing, suppose every developer has its own branch (branch per developer pattern). Ok, if developer B wants to see what developer A is doing (to have a look, to help, whatever), he just takes his branch. So, no need to access his home by NFS, just use the SCM. We internally use "branch per task" for our own development, so switching tasks is quite easy, and also sharing our work just "pointing" to what other developer is doing... pablo Well, what I wanted to say was that branches are useful not only to split development, but also to coordinate teams.

In the case you’re describing, suppose every developer has its own branch (branch per developer pattern). Ok, if developer B wants to see what developer A is doing (to have a look, to help, whatever), he just takes his branch. So, no need to access his home by NFS, just use the SCM.

We internally use “branch per task” for our own development, so switching tasks is quite easy, and also sharing our work just “pointing” to what other developer is doing…

pablo

]]> by: squadette http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-3 Sun, 10 Dec 2006 19:18:11 +0000 http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-3 hi, I believe it is because Google mostly does in-house development. The quote says "almost no developer branches". I guess that things that they do release externally, such as Google Talk and Google Desktop, have their (maybe short) branches with fixes etc. All other things I think just have rather short release cycle, so why bother. As for exporting using NFS, I think this just means that every developer can take a look into another developer's $HOME, so that's more of an open attitude. "and have it immediately solved" -- what is "it"? Thanks, hi,

I believe it is because Google mostly does in-house development. The quote says “almost no developer branches”. I guess that things that they do release externally, such as Google Talk and Google Desktop, have their (maybe short) branches with fixes etc.

All other things I think just have rather short release cycle, so why bother.

As for exporting using NFS, I think this just means that every developer can take a look into another developer’s $HOME, so that’s more of an open attitude.

“and have it immediately solved” — what is “it”?

Thanks,

]]> by: psluaces http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-2 Sun, 10 Dec 2006 14:27:44 +0000 http://versioncontrolblog.com/2006/12/03/perforce-as-the-version-control-system-at-google/#comment-2 I liked learning about the way they use their version control system. But a couple of questions showed up while reading: - While don't they use several branches? Well, my oppinon can be a bit biased, but Perforce is not very good on that... is maybe the reason? - Why do they export their workspaces using NFS?? Why don't they use the SCM for that?? I mean, they could use "branch per task" or "branch per developer" and have it inmediately solved... What do you think? pablo I liked learning about the way they use their version control system.

But a couple of questions showed up while reading:

- While don’t they use several branches? Well, my oppinon can be a bit biased, but Perforce is not very good on that… is maybe the reason?
- Why do they export their workspaces using NFS?? Why don’t they use the SCM for that?? I mean, they could use “branch per task” or “branch per developer” and have it inmediately solved…

What do you think?

pablo

]]>