Using TFS, is there a way to incorporate local/checked out?

vehro

We use a shared db, but using SQL Source Control interacts with the TFS server/db directly and not checked out copies of the code. So, 2nd developer checking in code will overwrite the 1st's if both started working on the same stored procedure before the first check in. I could not get it to work (generating an error/warning). If this could somehow interact with local (on our individual pcs), checked out copy, it could recognize what we'd checked out was stale and prevent the check in.

Maybe I'm missing something obvious?

Thanks.

David Atkinson

Yes, you're right, it interacts with source control directly. We are developing a new tool that integrates into VS, SQL Connect, which might serve your needs better.

http://www.red-gate.com/products/sql-de ... l-connect/

Let us know whether this would work for you.

If you'd prefer to stay in SSMS, an alternative might be to use SQL Source Control but instead of linking to TFS, instead link to a working folder that you link independently to TFS. This will mean that you have to check in to TFS as a separate step.

David Atkinson
Product Manager
Red Gate Software

vehro

I do want to stay in SSMS, but dont seem to be able to figure out how to do what you are saying. Do you have instructions for attaching to local checked out source files?

David Atkinson

I'm not sure if this is something that really makes sense. If Developer A changes Procedure A and Developer B makes a change to Procedure A, then Developer A's change will be overwritten unless he happens to have committed to the working folder first.

A solution to this is to ask your developers to not work on the same objects at the same time. If this is impractical, why not consider moving to the dedicated model, so each developer can make changes without any danger of overwriting others? What is the reason you are sharing a database if you're worred about overwriting each others' changes?

vehro

Keep in mind that we are currently evalulating the product, so the concept of dedicated vs shared is still being explored.

We mostly do not work on the same module of code at the same time and as a result >99% of the time it is not an issue.

In the meantime, I would like to explore linking to a working folder, using TFS as our source control, as you indicated:

"If you'd prefer to stay in SSMS, an alternative might be to use SQL Source Control but instead of linking to TFS, instead link to a working folder that you link independently to TFS. This will mean that you have to check in to TFS as a separate step. "

David Atkinson

In retrospect I'm not sure that this will help as it won't prevent two developers changing the same object on the shared database, so changes could still be lost.

Most SQL developers work on different objects and therefore clashes on a shared model don't happen enough for it to matter. If it's important to avoid these clashes, a dedicated model is recommended as this avoids the issue completely. Unless there's a strong reason why dedicated isn't possible for you, I'd advise you to try this out in the first instance.

StephanieHerr

If possible, I would recommend using the dedicated database model. Therefore, each developer would have their own copy of the database and their changes will NOT impact anyone else until the other users explicitly decide to Get Latest. Other users can see exactly what changes have been made before they update their copy.

With or without SQL Source Control, you will always have this problem of overwritting another developer's changes if multiple developers are working against the same db.

In a dedicated model, if 2 developers work on the same object, the first one to commit will have no problems. The second developer will see a conflict when they try to commit. They can decide to take the changes in source control and then they may need to reapply the changes that they made. Or, they can decide to keep their changes and reapply the other devs' changes. (For complex changes, I would recommend using a seperate merge tool to merge the 2 scripts.)

I'd love to hear more about your evaluation and anything that would prevent you from going to a dedicated model.

If you have to work on a shared model, then hopefully this will be rare when it could cause a problem like you say. All users should see blue indicators on the Object Explorer, which indicates changes which have not been committed yet. This is not the same as locking an object so other users can not edit it, but it could be a good warning that someone else currently has edits to that object, so I better wait till they're finished.

Currently, we have not implemented an exclusive checkout feature. You may want to vote comment on this feature request at https://redgate.uservoice.com/forums/39 ... ?ref=title.


I just had a quick chat w/ David... Unfortunately, linking to a working folder independent of TFS still won't help stop multiple users in the same database from overwriting each others' changes.

vehro

It would prevent us from overlaying each others code because the second person would fail in being able to check it in, since what they'd checked out won't match the TFS server, indicating it is out of date.

As I indicated, I'd like to consider dedicated vs shared, but in the meantime, can you please share the instructions for linking to a working folder?

Thank you.

David Atkinson

vehro wrote:

It would prevent us from overlaying each others code because the second person would fail in being able to check it in, since what they'd checked out won't match the TFS server, indicating it is out of date.

As I indicated, I'd like to consider dedicated vs shared, but in the meantime, can you please share the instructions for linking to a working folder?

Thank you.

When this situation occurs, SQL Source Control will flag a Conflict, and the second user has the responsibility to ensure that their changes are merged with the changes in source control before checking in again. There is no chance that the second user will commit to source control and overwrite another's changes by accident.

vehro

As I indicated, I'd like to consider dedicated vs shared, but in the meantime, can you please share the instructions for linking to a working folder instead of directly to TFS.

David Atkinson

Follow the instructions here:

http://www.red-gate.com/supportcenter/C ... 432725.htm

Essentially you select 'More' in the link dialog. This lets you specify a custom config file. Because we don't provide one for TFS (due to the built-in support) you will have to create your own using tf.exe .

David