3 ms·

We take for granted today that there are several fast, stable DVCS generally understood by an average engineer (in other words, the bar for using a DVCS has bee

by bdb 16y ago

We take for granted today that there are several fast, stable DVCS generally understood by an average engineer (in other words, the bar for using a DVCS has been lowered in the last few years and it's not a purely academic endeavor.) When Google was ramping up, Perforce was dramatically faster and more reliable than the almost all of its competitors. It was one of the most common source control systems to find at Valley companies. Why are they still using it? Inertia, I assume.

robfig 16y ago
I was way happier at Google using Perforce than I am today using Mercurial. The essential difference that annoys me to no end: - In Mercurial / Git, you must be synced to tip in order to push. (to avoid creating new heads) - In Perforce (and other old style VCS), you can commit as long as the files that you are committing are based on the newest version. It is impossible to have any sort of sizeable team commit to the same DVCS repo. With ~12 software engineers, I already have to sync 25 times a day, even if I'm the only one touching my area of the codebase. Most Google engineers commit to the same repository, and everyone gets the benefits of building from head (instant fix propagation from other systems, rather than waiting for releases). There is no way for everyone to work on the same repo with a DVCS afaik. It would require some sort of complicated hierarchy of repos.
- groby_b 16y ago
  If you do not sync and test your changes against the latest, I'd argue that you're being careless - how do you know things still interact properly? Feature branches are the way to work (for me). You're pretty much on your own in there, and once the thing's done you push to main.
  - nostrademons 16y ago
    If you don't sync and code against the latest, how do you know things still interact properly? This is the old optimistic vs. pessimistic locking debate. I remember that at my first job, we used SourceSafe, and it would lock the files when you check them out so that nobody else could edit it. When we switched to CVS, I asked "But what happens if people make incompatible changes to different regions of a file and conflict detection doesn't catch it?" The answer was "Then the next person who checks out the code gets a compile error and we deal with it. It just doesn't happen that often in practice." I've found that the problem you've had just doesn't happen that often. In the two years and hundreds of changes I've made at Google, I can think of a handful (< 5) of times that a CL has broken the build or caused a bug because of a bad sync and yet not caused any conflicts. And even then, the continuous build catches it and it either gets rolled back and tested properly before resubmit, or somebody patches it and we move on. I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on. This obviously depends on team size though - if you've got 10 developers working on a piece of code, it's going to have a lower change rate than if you have 500 developers working on it. Of course, if you have 10 developers working on the code, the chances are miniscule that one will submit something that conflicts with your change in the window after you sync & test, and you can just yell out across the room "Hey, anybody submitting anything that conflicts with my change?"
    - lars512 16y ago
      "I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on." DCVSs don't stop you from doing your commit, doing a naive merge, and then optimistically pushing. That option is still there, and is partly why so many people rebase before pushing their changes. Of course, pessimistic integration is equally available as an option. If you find the overhead so high, it suggests that it's process holding you back and forcing you to pessimistically integrate, rather than the DCVS doing so.
    - groby_b 16y ago
      > I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on. Not disagreeing. My current working theory is that integration difficulty increases exponentially with merge distance. And yes, team size is a factor - but I'd argue that if 500 developers all work in the same area of the code, something else is wrong :) To get back to the original point: You sync to head, and you compile. I'm not suggesting a full QA cycle, but especially if you changed APIs, that's the polite thing to do.
  - brown9-2 16y ago
    If you do not sync and test your changes against the latest, I'd argue that you're being careless - how do you know things still interact properly? This would suggest that the developer who checked in changes to A, which is used by B, did not also make the changes to B so that it works with the changes to A. That seems to be the actual careless action to me.
    - groby_b 16y ago
      The point of "sync & test before commit" is that for longer-lived branches, there's a good chance B only got created after you branched off. So unless you catch up to reality (i.e. sync), you won't even know you should make those changes to B. Hence my post ;)
- koenigdavidmj 16y ago
  You are not supposed to use one giant repo for everything. You are supposed to break it into pieces, one per project. See Android, which already has a wrapper around git ( http://source.android.com/source/git-repo.html http://source.android.com/source/git-repo.html ) to sync multiple repositories as a single unit.
  - benmccann 16y ago
    I'd rather not have my version control system dictate my project structure.
ebneter 16y ago
> Why are they still using it? Inertia, I assume. Well, that and that migrating to anything else would be a huge nightmare. They have a ton of infrastructure written around Perforce, just for starters. Then there's the fact that moving to, say, git, would require significant refactoring of their heavily incestuous code base. Moving to Subversion would be easier, but svn's problems with branching and merging would probably make that a non-starter.

by bdb 16y ago

robfig 16y ago

I was way happier at Google using Perforce than I am today using Mercurial. The essential difference that annoys me to no end: - In Mercurial / Git, you must be synced to tip in order to push. (to avoid creating new heads) - In Perforce (and other old style VCS), you can commit as long as the files that you are committing are based on the newest version. It is impossible to have any sort of sizeable team commit to the same DVCS repo. With ~12 software engineers, I already have to sync 25 times a day, even if I'm the only one touching my area of the codebase. Most Google engineers commit to the same repository, and everyone gets the benefits of building from head (instant fix propagation from other systems, rather than waiting for releases). There is no way for everyone to work on the same repo with a DVCS afaik. It would require some sort of complicated hierarchy of repos.

groby_b 16y ago
If you do not sync and test your changes against the latest, I'd argue that you're being careless - how do you know things still interact properly? Feature branches are the way to work (for me). You're pretty much on your own in there, and once the thing's done you push to main.
- nostrademons 16y ago
  If you don't sync and code against the latest, how do you know things still interact properly? This is the old optimistic vs. pessimistic locking debate. I remember that at my first job, we used SourceSafe, and it would lock the files when you check them out so that nobody else could edit it. When we switched to CVS, I asked "But what happens if people make incompatible changes to different regions of a file and conflict detection doesn't catch it?" The answer was "Then the next person who checks out the code gets a compile error and we deal with it. It just doesn't happen that often in practice." I've found that the problem you've had just doesn't happen that often. In the two years and hundreds of changes I've made at Google, I can think of a handful (< 5) of times that a CL has broken the build or caused a bug because of a bad sync and yet not caused any conflicts. And even then, the continuous build catches it and it either gets rolled back and tested properly before resubmit, or somebody patches it and we move on. I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on. This obviously depends on team size though - if you've got 10 developers working on a piece of code, it's going to have a lower change rate than if you have 500 developers working on it. Of course, if you have 10 developers working on the code, the chances are miniscule that one will submit something that conflicts with your change in the window after you sync & test, and you can just yell out across the room "Hey, anybody submitting anything that conflicts with my change?"
  - lars512 16y ago
    "I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on." DCVSs don't stop you from doing your commit, doing a naive merge, and then optimistically pushing. That option is still there, and is partly why so many people rebase before pushing their changes. Of course, pessimistic integration is equally available as an option. If you find the overhead so high, it suggests that it's process holding you back and forcing you to pessimistically integrate, rather than the DCVS doing so.
  - groby_b 16y ago
    > I've found that any feature branch that lives longer than a week becomes essentially impossible to integrate - in the time necessary to bring it up to head, head has changed enough that you then need to integrate it again, and so on. Not disagreeing. My current working theory is that integration difficulty increases exponentially with merge distance. And yes, team size is a factor - but I'd argue that if 500 developers all work in the same area of the code, something else is wrong :) To get back to the original point: You sync to head, and you compile. I'm not suggesting a full QA cycle, but especially if you changed APIs, that's the polite thing to do.
- brown9-2 16y ago
  If you do not sync and test your changes against the latest, I'd argue that you're being careless - how do you know things still interact properly? This would suggest that the developer who checked in changes to A, which is used by B, did not also make the changes to B so that it works with the changes to A. That seems to be the actual careless action to me.
  - groby_b 16y ago
    The point of "sync & test before commit" is that for longer-lived branches, there's a good chance B only got created after you branched off. So unless you catch up to reality (i.e. sync), you won't even know you should make those changes to B. Hence my post ;)
koenigdavidmj 16y ago
You are not supposed to use one giant repo for everything. You are supposed to break it into pieces, one per project. See Android, which already has a wrapper around git ( http://source.android.com/source/git-repo.html http://source.android.com/source/git-repo.html ) to sync multiple repositories as a single unit.
- benmccann 16y ago
  I'd rather not have my version control system dictate my project structure.

ebneter 16y ago

> Why are they still using it? Inertia, I assume. Well, that and that migrating to anything else would be a huge nightmare. They have a ton of infrastructure written around Perforce, just for starters. Then there's the fact that moving to, say, git, would require significant refactoring of their heavily incestuous code base. Moving to Subversion would be easier, but svn's problems with branching and merging would probably make that a non-starter.