3 ms·

In my experience, if you have high bandwidth communication (e.g. a team room) then trunk based development scales to well beyond 2-3 people. I've seen it work o

by zeendo 11y ago

In my experience, if you have high bandwidth communication (e.g. a team room) then trunk based development scales to well beyond 2-3 people. I've seen it work on at least one large distributed teams (3 team rooms, 3 time zones, ~30 developers)..and it regularly works on teams of 6-10 developers. Regarding VSS and exclusive locks. No. Trunk based development with no exclusive locks is fine. Pessimistic locking was unwarranted pessimism when applied to source control. Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too?

radicalbyte 11y ago
In that case you were absolutely having merge conflicts - only you were forced to resolve them the second you updated your local working copy. Over the years I've lost so much time to small errors resolving merges - particularly the type which involved cross-file refactoring (where two people have moved methods and then refactored them). The beauty of using branches - especially with Git - is that you as developer gain a lot of power over how you apply merges. The "pre" state is also under version control, so you can always go back. Plus if you're using Git then you're implicitly doing branch-based development (git clone creates a local branch). My current team of 6 developers switched from TFS trunk-based to Git with short-lived feature branches and they've not looked back. We've greatly reduced merge issues and downtime caused by bad check-ins. Both still happen, only less than before.
- zeendo 11y ago
  Of course we still have merge conflicts. You do too. Or is your work just organized such that no two people are ever working on the same file concurrently? If it is then you'd not have any merge conflicts with trunk based development either. Fundamentally merge conflicts are unavoidable. The claim by the trunk based development crowd is that smaller, but more frequent merge conflicts produce fewer mistakes. Trunk based development leads to smaller merges because you do them more frequently. That's about it.
  - spinningarrow 11y ago
    Working on the same file concurrently does not guarantee conflicts - working on the same code does. We recently switched to short-lived feature branches (short-lived as in a couple of days maximum), and I haven't had to resolve merge conflicts in months. Our feature branches previously used to last around two weeks and merging things in was collectively not looked forward to. Now I don't even have to give it a second thought. tl;dr not having merge conflicts is an entirely possible happy reality.
    - zeendo 11y ago
      Sure. My point is that avoiding merge conflicts has nothing to do with your branching strategy...it has to do with what work you parallelize.
ExpiredLink 11y ago
> Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too? Yep! http://paulhammant.com/2013/04/05/what-is-trunk-based-development/ http://paulhammant.com/2013/04/05/what-is-trunk-based-develo...

by zeendo 11y ago

radicalbyte 11y ago

In that case you were absolutely having merge conflicts - only you were forced to resolve them the second you updated your local working copy. Over the years I've lost so much time to small errors resolving merges - particularly the type which involved cross-file refactoring (where two people have moved methods and then refactored them). The beauty of using branches - especially with Git - is that you as developer gain a lot of power over how you apply merges. The "pre" state is also under version control, so you can always go back. Plus if you're using Git then you're implicitly doing branch-based development (git clone creates a local branch). My current team of 6 developers switched from TFS trunk-based to Git with short-lived feature branches and they've not looked back. We've greatly reduced merge issues and downtime caused by bad check-ins. Both still happen, only less than before.

zeendo 11y ago
Of course we still have merge conflicts. You do too. Or is your work just organized such that no two people are ever working on the same file concurrently? If it is then you'd not have any merge conflicts with trunk based development either. Fundamentally merge conflicts are unavoidable. The claim by the trunk based development crowd is that smaller, but more frequent merge conflicts produce fewer mistakes. Trunk based development leads to smaller merges because you do them more frequently. That's about it.
- spinningarrow 11y ago
  Working on the same file concurrently does not guarantee conflicts - working on the same code does. We recently switched to short-lived feature branches (short-lived as in a couple of days maximum), and I haven't had to resolve merge conflicts in months. Our feature branches previously used to last around two weeks and merging things in was collectively not looked forward to. Now I don't even have to give it a second thought. tl;dr not having merge conflicts is an entirely possible happy reality.
  - zeendo 11y ago
    Sure. My point is that avoiding merge conflicts has nothing to do with your branching strategy...it has to do with what work you parallelize.

ExpiredLink 11y ago

> Also, note that Google is trunk based...with a single trunk across the whole company. I think Facebook is too? Yep! http://paulhammant.com/2013/04/05/what-is-trunk-based-development/ http://paulhammant.com/2013/04/05/what-is-trunk-based-develo...