Hacker News Reader

Comment by robfig | Hacker News Reader

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.

View on HN

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.

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?"

"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.

> 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.

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.

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 ;)

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 ) to sync multiple repositories as a single unit.

I'd rather not have my version control system dictate my project structure.

Reply on news.ycombinator.com