Skip to content
← SQL Source Control

How can we improve SQL Source Control?

SQL Source Control: Better Support for Shared Db Dev Model

Categories

JUMP TO ANOTHER FORUM

(thinking…)

Don't show conflicts when working in a Shared (Centralized) DB Model

In a dedicated db model, a conflict will occur when User1 and User2 both make a change to Table1. User1 commits the change successfully. When User2 tries to commit, they will be notified of the conflict. User2 must then decide if they want to take what's in source control or keep their version and commit this to source control. In either case, User2 may need to reapply some changes to the db and re-commit.

In a centralized db model, when all developers are working against the same db, these conflicts should NOT occur.

10 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Rob van den Bijtel shared this idea  ·   ·  Report…  ·  Admin →

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Tobias Manthey commented  ·   ·  Report

    When do you solve this issue? We are working with a centralized model and source control is currently unusable in this scenario.

  • Phil commented  ·   ·  Report

    If where the files were stored was configurable, maybe the files could stored on a network share instead? That would mean that the shared development database could work without the issue of people having their own local copies of the files and the problem would go away. The issue then becomes one of file locking.

  • AdminRedgate Administrator (Admin, Redgate) commented  ·   ·  Report

    I just wanted to clarify the differences between a dedicated and centralized db development model.

    Dedicated DB Model
    Each developer has their own copy of the db. This could be on their own local server or just a seperate db on a centralized db server. Developers commit their changes to source control, which provides a history of who made what change, when, and why. Then developers get changes from source control that have been committed by other developers. This is how application developers work with source control and ensures that each developer's changes are NOT overwritten or a change that breaks something while in development does NOT impact others.

    Centralized DB Model
    All developers connect to the same db on the same centralized db server and make changes directly on the same shared db. Developers will commit their changes to source control, which provides a history of who made what change, when, and why.

  • Rob van den Bijtel commented  ·   ·  Report

    With the new option to keep mine I can solve the conflict to resolve.
    I still don't think that there really is a conflict in our situation, but with this new feature I can resolve it without a problem.
    So it works for us.

  • Rob van den Bijtel commented  ·   ·  Report

    I've just installed SQL Source Control and linked it to a development database.
    A number of developers is using this database. In our team I'm the only one who is using the tool.
    On the "Commit changes" tab I got all the components and succesfully committed it to the SVN server.
    When a developer changed a function,table or procedure I could directly see the change.
    However at the end of the day I closed the Management Studio.
    The next day when I opened the Management Studio and opened the database the link with source control was broken. After linking the database again, several conflicts arose.
    The new changes of that day on the database were presented as conflicts.
    This is not correct as only on the database changes had taken place .