Merge Conflicts with SQL Server Database Project

  • I hope someone more familiar with database projects can provide me some guidance.

    I am currently trying to introduce a better source control solution and automated deployment solution for a project I have joined.

    The current state is I have a database project in Visual Studio 2019 which will be used to maintain an Azure SQL Database.  When a single developer is using the project they will do the following to made changes.

    1. Clone the Azure repo master branch to their local host
    2. Create a new feature branch
    3. Add their changes, commit and push the changes back to the repo
    4. Create a pull request to merge the changes
    5. PR is merged
    6. Azure pipeline is triggered to build the database project and create an artifact for deployment
    7. Azure release pipeline is triggered to deploy the database change to the Azure SQL DB

    Now the above works fine when changes are being implemented by a single developer, however when changes are being made to the same repo by multiple developers each on their own feature branch once the PR is created we are encountering merge conflicts on the .sqlproj file and .refactorlog file.  This makes sense as although they may have been working on unrelated files such as new sql files for table creation or procedure modifications these changes are also refeclected in their own copy of the project and refactor log files.  When trying to merge their PR's a conflict is always likely as those files are being modified by sepearte PR's.

    Has anyone any experience of preventing these merge conflicts to the master branch where you have multiple developers all working on the same repo but from different feature branches?

    MCITP SQL 2005, MCSA SQL 2012

  • After each merge make the remaining teams (with unmerged code) pull from the master (or the newer, more pc, 'main') branch.  The team with the least seniority makes the last merge 🙂

     

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • Hi Steve I'm not sure I fully understand you suggestion.  Take this scenario:

    1. DevA creates a new feature branch from master
    2. DevB also creates a new feature branch from master
    3. Both of the above have the same starting point (i.e. both createed their feature branch from master at the same commit state)
    4. DevA adds a new procedure, commits and creates a PR to merge their changes to master
    5. DevB adds a new procedure, commits and creates a PR to merge their changes to master

    At this point there is 2 PR's raised, neither has been reviewed or approved yet for merge to master.

    The PR for DevA will merge without issue as raised first so is approved and merged.

    The PR for DevB will now no longer merge successfully due to the merge conflict caused by the merge of DevA's PR.

    Are you saying that DevB should now merge master into their branch so that they will have all commits added to master since their feature branch was created?  If you are this then also causes a merge conflict on the feature branch with the same two files as they have changed in master and in the feature branch.

    Ideally I am trying to establish if it's possible to avoid the merge conflicts entirely but still have a working project that will sucessfully build.

    MCITP SQL 2005, MCSA SQL 2012

  • Just a note after some further testing, in the example above merging master into the DevB PR does resolve the PR merge conflict.  In this case I have to choose the merge option of keeping both changes,  its not ideal as it gets messing if the PR has lots of changes but could potentially work as a compromise.

    MCITP SQL 2005, MCSA SQL 2012

  • For independent groups to modify the same set of objects and end up with code which combines the best elements of each somehow the merge conflicts must be dealt with, no?   If you get all of the teams in a room/zoom and proceed to merge multiple pull requests into the same master trying to do so hierarchically by seniority would quickly become ridiculous.  That was sarcasm.  Actual teamwork could/should occur to determine a good way forward.  Hopefully.  Hopefully teamwork already happened to reduce the necessity for multiple teams to modify the same object(s) independently.  You could try to batch up changes (perhaps with an impressive label, like an "agile push", or "git flow arc") and then get everyone in a room/zoom.  If you split apart #4 and #5 on the list, then perhaps both "merge their changes to master" could be #6 room/zoom.  Otherwise, my post suggested a "hub and spoke" approach where git pulls from master/main are made in succession so each team handles merges back into their own branch.  In theory the last merge would be without conflict.  Actual teamwork imo works well when given a chance 🙂 because the alternative is not as good

    Aus dem Paradies, das Cantor uns geschaffen, soll uns niemand vertreiben können

  • one way of doing it

    Merge manager should decide (within team) which change should go first

    developer A
    --> Local -- Remote
    --> Master -- master
    --> project_change_A - created from the local copy of master
    --> push to remote - new branch
    --> create merge request onto master (Remote)

    developer B
    --> Local -- Remote
    --> Master -- master
    --> project_change_B - created from the local copy of master
    --> push to remote - new branch
    --> create merge request onto master (Remote)

    Merge Manager
    --> Merge from Dev A is accepted and merged onto remote master
    --> Merge from Dev B now has conflicts - Rejects Merge
    --< Dev B must apply new changes to their local branch and push to remote again
    --> Deletes project_change_A from remote - Dev A should remove it also from local

    Developer B
    --> refreshes local copy of master - now includes changes from DevA
    --> Merge local master onto project_change_B

    --> push to remote - overrides previously created branch
    --> create merge request onto master (Remote)

    Merge Manager
    --> Merge from Dev B is accepted and merged onto remote master
    --> Deletes project_change_B from remote - Dev B should remove it also from local


  • I understand what you are saying but in this particular instance the developers are working in isolation on seperate objects within seperate schemas and due to the nature of how database projects work in VS it does not lend itself to parrallel development on seperate branches.

    Take my example above:

    DevA adds a single file to the project in the location schema1\Tables\t_fancyfeature1.sql

    DevB adds a single file to the project in the location schema37\Tables\t_fancyfeature37.sql

    Neither is working within the same schema or indeed the same files however each time a file is added to a Visual Studio Database Project an entry for each new file is added to the .sqlproj file automatically as a result of the developers actions of adding an object rather than something that perform themself.

    In the case of DevA the .sqlproj file has been modified by visual studio itself adding these 3 lines, lets say at lines 30,31 and 32 in the file

    <ItemGroup>
    <Build Include="schema1\Tables\t_fancyfeature1.sql" />
    <ItemGroup>

    In the case of DevB the same file has been modified but as it is not aware of the additions from the other branch which has not yet been merged to master it also adds 3 lines at the same line numbers

    <ItemGroup>
    <Build Include="schema37\Tables\t_fancyfeature37.sql" />
    <ItemGroup>

    Whilst your points are entirely valid if various developers were actively modifying the same files I would agree its a co-ordination and communication issue but in this case, in my opinion it is an issue with how database projects in visual studio do not lend themselves to concurrent development utilising a feature branch method.

    MCITP SQL 2005, MCSA SQL 2012

  • frederico_fonseca wrote:

    one way of doing it

    Merge manager should decide (within team) which change should go first

    developer A
    --> Local -- Remote
    --> Master -- master
    --> project_change_A - created from the local copy of master
    --> push to remote - new branch
    --> create merge request onto master (Remote)

    developer B
    --> Local -- Remote
    --> Master -- master
    --> project_change_B - created from the local copy of master
    --> push to remote - new branch
    --> create merge request onto master (Remote)

    Merge Manager
    --> Merge from Dev A is accepted and merged onto remote master
    --> Merge from Dev B now has conflicts - Rejects Merge
    --< Dev B must apply new changes to their local branch and push to remote again
    --> Deletes project_change_A from remote - Dev A should remove it also from local

    Developer B
    --> refreshes local copy of master - now includes changes from DevA
    --> Merge local master onto project_change_B

    --> push to remote - overrides previously created branch
    --> create merge request onto master (Remote)

    Merge Manager
    --> Merge from Dev B is accepted and merged onto remote master
    --> Deletes project_change_B from remote - Dev B should remove it also from local


    Thank you for the reply,  this does affirm my suspicions that due to how the .sqlproj file is used in the project its almost inevitable merge conflicts will exist which will result in having to manually resolve merge conflicts.

    MCITP SQL 2005, MCSA SQL 2012

  • Yes and no - majority of cases the merge by the second developer will be without conflicts - only in a few cases will the developer be required to manually select which changes will be picked up by the merge.

    we use this on one of my current projects - 95% of the times the merge has no conflict - steps still need to be followed as I stated, but its straightforward.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply