First let me preface by saying, I've asked similar questions here before, and never gotten a good answer that solved my lack of knowledge/problem.
First, let me start this off with a branching strategy proposal. This is what we have at work, and I'm happy to hear comments otherwise, and as to why this sucks. But understand that it generally works for us.
We have 1 product. For the sake of this example, lets call it "PRODUCT". We run 2 concurrent development cycles. A weekly maintenance cycle, where we fix non-pressing bugs, and a bi-weekly sprint. There are 2 branches created from trunk called "Sprint" and "Maintenance"(shocking name choice I know!). Also for urgent/blocker issues, fixes are made directly into trunk and pushed to production after testing.
9 times out of 10 when I try to reintegrate the sprint or maintenance back into the trunk I get LARGE amounts of conflicts. On files that were never even worked on in one of the branches. This then leads to lots of manual merging, which sucks, and tends to lead to more problems.
So I will issue command: svn merge --reintegrate http://repo/Sprint and while some files will update, I will have conflicts on files that are EXACTLY identical(via WinMerge). I don't know what causes these conflicts.
How can I stop having these ridiculous conflicts?
One answer is to use many small feature branches, not two fixed branches. Your problem is that changes from your fixed branches get merged, and then you do some more changes on the fixed branches and those changes appear to conflict with the first merge, even when they really don't.
So either use many small feature branches, or switch to a DVCS like Mercurial or git which handles merging in a more intelligent way than SVN currently does.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With