Hi, > Well, there might be a better way, but by your reasoning we would never > branch. No I am against have a single unstable branch. I see far less issues if we did use multiple branches (ie one branch per change) OR most small changes in trunk and branch when needed as suggested by the SVN best practice document.
>> We not talking about the git branching model we are talking about using a >> single unstable branch or so I thought? > Not in this thread, see subject. OK so just to confirm you now think that a singe unstable branch is not the way to go? > Maybe you can provide an example? I don't see how one way pushes from > unstable/develop can cause a conflict in trunk. Because of existing changes that have not been pushed into trunk. Person A checks in files A,B and C (in one changeset), Person B modifies and checks in file B, Person A then modifies and checks in file B again all in a non trunk branch. Merging persons A changeset with trunk could then likely to cause an issue and the trunk may not be in a usage state. To fix that you then have to make changes directly to trunk and then you would need to sync those changes with the branch. The simple way around this issue is to always merge entire branches. I also read carefully the "More on Merge Conflicts" section in the link you provide. Yes you can cherrypick and block changesets (and shown in the link you provided) but it's seem overly complex to need to do that all the time rather than is just exceptional circumstances. > In the Git Branching Model, when we decide we want to prepare a release > (which would not be daily) we would cut a release branch from develop and > either take a bunch of known good commits or take from the head, remove and > block. In which I think you run into the same issues as above re using a single branch and selecting changesets. > In the Git Branching Model, you would do the merge, resolve conflicts and > block manually resolved conflicts. Which doesn't answer my question of how you would keep develop/unstable in sync with the trunk. (See above). > I think the trunk history may not be any different if we use the Git > Branching Model entirely in SVN because the only commit to trunk is from a > release branch merge operation. Can you think of any way to keep the revision history? It's sometime very useful to know what small changes were made when, rather than knowing a whole lot of files and lines changed in this release. Thanks, Justin
