Check out?

Paule

I haven' t testet the product yet. But one thing is unclear to me.
If multiple developers start to work on the same procedure, how can they check out an db Object so that anybody Else could Not Modify it too?

neil.anderson

Hi,

Thanks for your post. Assuming you are talking about the situation where multiple people are working on the same Oracle instance you can "check out" or lock an object as outlined here:

http://documentation.red-gate.com/displ ... ng+objects

The developer locks an object from modifications and until he unlocks it other users are prevented from modifying it. He can continue to work and other users will get an error if they try to change it.

Thanks,
Neil

Paule

Neil,
OK, locking is working.
We now try to evaluate Redgate Source Contol in combination with TFS in the team.

For me it is not 100% clear, how we can manage a "central" locking?

Let's look at the following scenario for instance:

1. Two developers start to work on the same Oracle package at the same time. The are using different databases.
2. They check their current version and get the latest version from TFS via Redgate and start to work.
3. After some time Developer 1 check in his new version containing a new procedure 'a' into TFS via Redgate.
4. Afterwards Developer 2 check in his new version containing a new procedure 'b' into TFS via Redgate, but procedure 'a' is missing in the latest version.

How to handle such a scenario?
Why is a central locking in e.g. TFS not supported?
Thanks,
Paule

Michael Christofides

Hi Paule,

I work with Neil on the Oracle team, as Product manager I feel perhaps locking is still a confusing feature of the tool.

Our aim with locking was to provide teams working on shared development schemas a means by which to 1) avoid clobbering each others' changes accidentally and 2) communicate what they were working on to one another.

The use case you describe is something we see less, but that we understand would be valuable to some teams working on separate, sand-boxed, development schemas. We currently see a better long-term solution to that problem to be to offer a "merge" to the second person, but in the meantime we currently offer a "take mine" or "take theirs" to resolve the conflict. There is nothing stopping you at that point going to either the database or the file system and merge the object yourself.

Hopefully that helps?

Best regards,
Michael