4 ms·

The thesis of this post is that merge conflicts basically negate all of the other benefits a branched workflow provides. I'm not sure how the workflow the autho

The thesis of this post is that merge conflicts basically negate all of the other benefits a branched workflow provides. I'm not sure how the workflow the author suggests deals with concurrent changes to code otherwise though, and I feel like merge conflicts are preferable to changes that overwrite other changes. Not taking advantage of branching destroys much of the benefit a DVCS provides. In order for this workflow to be reasonable for any development team of a size greater than about 3, each commit would need to move all the code in to a working state. While a reasonable pattern in theory (Don't TRY commit breaking changes!), it is frequently useful to track code in an intermediate state. Sometimes (read frequently), this code may not be representative of the final state of the technology or may not even work as it should. Not maintaining individual branches means that these changes are exposed to the entire team and can be very very messy. All in all, what a silly approach to revision control. Take advantage of the latest patterns and a system that provides the loosest coupling and highest distribution. If we do as the author advocates, we might as well all just switch back to CVS...

Negitivefrags 11y ago
We have a team of 50 and single branch works well for us. > merge conflicts are preferable to changes that overwrite other changes Nobody is saying that. The difference is really merging as you go vs doing one big merge at the end. I personally fall on the side that it's far easier to merge as you go.
- techman9 11y ago
  You merge as you go in branched development too? Master is typically periodically pulled into the feature branch to ensure you're working against the most current version of the codebase. EDIT: Yes, this can create an ugly revision history, but that's what rebasing is for, right?
  - lowmagnet 11y ago
    We rebase main branch into feature branches constantly. We rebase to squash reviewed features, and then ff down to the main branch to integrate the feature. If something doesn't integrate well, we commit the appropriate fixes locally, squash locally (if necessary) and pull/rebase/repeat on changes. It sounds crazy now that I write it down, but it really keeps our commits clean.
  - zeendo 11y ago
    If everyone is working in feature branches then you're still merging less often. Until you've merged your work into master then I'm not merging it into my feature branch. That leads to bigger merges than if everyone is committing to master all the time. Pros or cons of each aside, advocates of feature branch based development should recognize that they are merging less often than they would if they were doing trunk based development.
ben_bai 11y ago
Branching/merging in DVCS is only easy if there are no merge conflicts. Checking in code to the VCS that makes the tree NOT build will get you screamed at (at least within the OpenBSD project). This requires proper planning for big changes, and to break them down into small, easy to review, patches. OpenBSD uses CVS as main repo because it fits their development style. Bevore you knock down CVS look at AnonCVS and cvsync. http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/ http://www.openbsd.org/papers/asiabsdcon2009-release_enginee...

Negitivefrags 11y ago

We have a team of 50 and single branch works well for us. > merge conflicts are preferable to changes that overwrite other changes Nobody is saying that. The difference is really merging as you go vs doing one big merge at the end. I personally fall on the side that it's far easier to merge as you go.

techman9 11y ago
You merge as you go in branched development too? Master is typically periodically pulled into the feature branch to ensure you're working against the most current version of the codebase. EDIT: Yes, this can create an ugly revision history, but that's what rebasing is for, right?
- lowmagnet 11y ago
  We rebase main branch into feature branches constantly. We rebase to squash reviewed features, and then ff down to the main branch to integrate the feature. If something doesn't integrate well, we commit the appropriate fixes locally, squash locally (if necessary) and pull/rebase/repeat on changes. It sounds crazy now that I write it down, but it really keeps our commits clean.
- zeendo 11y ago
  If everyone is working in feature branches then you're still merging less often. Until you've merged your work into master then I'm not merging it into my feature branch. That leads to bigger merges than if everyone is committing to master all the time. Pros or cons of each aside, advocates of feature branch based development should recognize that they are merging less often than they would if they were doing trunk based development.

ben_bai 11y ago

Branching/merging in DVCS is only easy if there are no merge conflicts. Checking in code to the VCS that makes the tree NOT build will get you screamed at (at least within the OpenBSD project). This requires proper planning for big changes, and to break them down into small, easy to review, patches. OpenBSD uses CVS as main repo because it fits their development style. Bevore you knock down CVS look at AnonCVS and cvsync. http://www.openbsd.org/papers/asiabsdcon2009-release_engineering/ http://www.openbsd.org/papers/asiabsdcon2009-release_enginee...