Options

SQL Source Control does not show changes done by other authors

Hello All,

I am totally new to Redgate Toolbelt and I might come up with a number of questions on the forum. Anyway, I am using the latest version of SQL source control (Version 5.7.6.6321) and if there are 2 different authors making changes in the same object, while viewing the history for the objects, we are not able to see changes from all authors.

E.g. If user A and B are making changes in the object C. User A can view only the history pertaining to user A and the same goes for user B.

What do I need to do in order to view the full history? User A should be able to view all the changes done by user B and vice versa.

Regards,
Anant

Comments

  • Options
    Can you tell me what version control system you are using (e.g. Git, TFS, SVN, working folder mode) and whether you selected shared or dedicated mode when you linked?
    Development Lead
    Redgate Software
  • Options
    Anant10486Anant10486 Posts: 5 New member
    Hello Mike,

    It is TFS and Shared Mode.

    Regards,
    Anant
  • Options
    AlexYatesAlexYates Posts: 264 Rose Gold 2
    edited August 10, 2017 2:56PM
    Hi Anant,

    Did user A and B commit their changes yet or are we talking about uncommitted changes?

    The history is read from the source control system, in your case TFS. If user A and user B had not yet committed changes you just see the last TFS version vs latest db version and the most recent author's username in the commit tab. (This information is retrieved from the default trace).

    If both users had committed to source control I would have expected both changes to show up in the history tab. If this is not happening probably you should speak to the dev team. (Mike U :-)

    Of course, this does mean there is a possibility that one user might overwrite another persons code if the first developer had not yet committed to source control. If this concerns you take a look at the locking feature:
    https://documentation.red-gate.com/display/SOC5/Lock+an+object

    However, a better fix would be to switch to using the dedicated model if possible.
    Alex Yates
    DevOps Mentor and Coach

    Director of DLM Consultants
    Creator of Speaking Mentors
    Microsoft Data Platform MVP
    Friend of Redgate
    Twitter / LinkedIn
  • Options
    Anant10486Anant10486 Posts: 5 New member
    Hello Alex,

    Thank you for the reply. Both the users have committed their changes and I am well aware of the locking of objects too.
    We need to have shared model as there will be multiple persons working on the same objects on daily basis.

    I will still do some try and error testing but I do not think it will help.

    I can send Mike a meeting invite to show the live demo of the issue we are facing.

    Regards,
    Anant
  • Options
    AlexYatesAlexYates Posts: 264 Rose Gold 2
    OK - sounds like either the product either isn't configured correctly or isn't working properly. I'll let you figure that out with the folks from Redgate.

    However, I would pick up on your point about people changing the same objects at the same time. That's often exactly why people like to use the dedicated model. The dedicated model handles conflicts much more elegantly and avoids the risk that one developer will accidentally overwrite the other developer's code.

    Imagine the database was C# source code. The dedicated model is a bit like everyone having their own checkout or locel repo - which is the conventional way of working. In contrast, the shared model is like sticking your source code on a file share and letting everyone edit it at the same time.
    Alex Yates
    DevOps Mentor and Coach

    Director of DLM Consultants
    Creator of Speaking Mentors
    Microsoft Data Platform MVP
    Friend of Redgate
    Twitter / LinkedIn
  • Options
    Anant10486Anant10486 Posts: 5 New member
    Hello All,

    The issue has been resolved. For the other user, the selected model was Dedicated instead of Shared. I have changed it to Shared Model and it works like a charm.

    Thank you Alex and Mike for your help on this.

    Regards,
    Anant
Sign In or Register to comment.