0

We had a ten developers who do commits in the dev branch. After a week once all the tasks are through, i need to merge all the commits to test branch for rebasing before i tag and merge the releases to trunk. While merging a range of revisions i am getting strucked and time consuming to resolve with svn conflicts. When i get conflict : I used to do the following :

  1. I allways consider the latet revision file for eg: .r500 is the latest revision which i need, and removing the extension it generate like filename.java.rev500, and deleting the remaining like mine,base file and previsous revision files which it genrates when the conflicts occur. Is this a best practise and advisable.I allways use diff in the log and check the latest version file manually while considering a revision when i get the conflict.

  2. While merging most of the conflicted, updated files i am getting these symbols, <<<<<<< .working and >>>>>>> .merge-right.r500. Do we need to manually remove this in the files, when we perform releases. Even some times these symbols effect my build, resolving after i manually remove them.

  3. Is it advisable to merge 15 to 20 revisions at a time, for eg: consisting 70 files in the entire release, is it better to merge 4 to 5 revisions solve the conflicts and move forward with remaning revisions, but if i merge few revisions and again after with remaining revisions its conumes a lot of time. When ever i do merge, i should allways manually edit, or any best methods and practises i need to follow.

borrible
  • 17,120
  • 7
  • 53
  • 75
Gopinath Karangula
  • 133
  • 5
  • does the test branch changes a lot? do you have other development branches that end up in trunk? – Andrey Adamovich Jul 05 '11 at 12:01
  • how often do you release? what is the amount of changes/revisions your developers produce between releases? – Andrey Adamovich Jul 05 '11 at 12:03
  • is anyone doing changes to trunk except you (the merger)? – Andrey Adamovich Jul 05 '11 at 12:05
  • i have only the one dev branch, where i merge the range of revisions to my test branch check the raw build to see the impact, i am the one who do perform release manamgement, creates branches, users, merging the branches to branches, trunk and tags the release. Well it depends on the client requirement,I am managing the Opentaps erp / crmsfa code, and on an average for every release 4 to 5 tasks with 50 to 70 files of code changes happen with 10 to 15 Mb of additional code. – Gopinath Karangula Jul 05 '11 at 12:05
  • if test/trunk branches are not changed by anyone, why do get conflicts? – Andrey Adamovich Jul 05 '11 at 12:10
  • My developers, commit the code repeatedly, for eg: changing line no 20 in the file again and again commit the same file twice or thrice uptill the task full fill after integrating in the test sever. – Gopinath Karangula Jul 05 '11 at 12:20

1 Answers1

0

To avoid many conflicts you need to have only one active development branch, or at least one development branch per repository subtree (e.g. project1, project2).

From what you write I can see that test/trunk branches have a lot of changes either. That's why you get so many conflicts. You need to merge changes back from test and trunk branch to dev. This will reduce the amount of conflicts.

In general you should try to avoid many parallel active branches that work on the same code base as otherwise you cann't avoid many conflicts.

Also you may put some work on developers. If they fix something in test branch, their task should also be to merge it to dev branch. This again will reduce conflict amount.

Andrey Adamovich
  • 20,285
  • 14
  • 94
  • 132
  • I had only one active branch, where i allow my developers to commit the code on the dev branch. I had one more branch for rebasing the release, and merge the revisions, where i need not disturb the active dev branch, do all my merge and releases using this test branch. I stablise the code in the test branch and ones it is stabilised, i merge the test branch to trunk and tag the revision. – Gopinath Karangula Jul 05 '11 at 12:17
  • what do you mean under "stabilise"? do you fix bugs? – Andrey Adamovich Jul 05 '11 at 12:19
  • if it's only you who makes changes in trunk/test and all those changes come from dev branch, then trunk/test should be an exact copy of dev after you did the merge, unless your "stabilisation" really is really a big thing – Andrey Adamovich Jul 05 '11 at 12:21
  • I would suggest merging "stabilisation" result both to dev and to trunk – Andrey Adamovich Jul 05 '11 at 12:21
  • stabilisation in the sense, we do fix the bugs, add patches, some times i get a range of revisions to merge, where in some revisions i get task to merge for eg: rev 500 consists 7 to 10 files ( my developers commit the entire task a single revision), i need to be not to consider some files in particular revision, where i couldnt do this in tortoise svn, i merge all files and in the latest commits, where the files of particular revision which shouldn't be considered will update in the latest revision.Is there any provision that i can exlude some files, when i perform a range of revision merge. – Gopinath Karangula Jul 05 '11 at 12:26
  • yes ill get the exact copy of dev, but my major time im strucking with resolving the conflicts, i am looking for some useful tips, how i can tackle when i get a major release consists of 100 files, on an average 70 files merge in regular i get conflict 10 to 15 files and some time more depends on the code. – Gopinath Karangula Jul 05 '11 at 12:41
  • as I tried to say before: when you do a bug fix in test branch, merge that fix to dev branch immediatly, this will reduce the amount of conflicts in next release. also check that merge errors do not come formatting problems, force all developers to use the same formatting rules (modern IDEs allow to automatically format the code on save). also another helpful thing can be a "commit freeze" during the time you make a merge. – Andrey Adamovich Jul 05 '11 at 12:59