I work in a team of 5 people on an oracle database. The problem we have is that because we only have one dev database, if we modify the same package we overwrite each others work. At the moment we just scream across the room saying that you are making changes to that package, and no-one else is to have that package open until you have finished with the package. This can slow down development.

I was wondering whether anyone has had a similar problem and how you solved this problem?

Thanks

Apache Subversion

We already use subversion for source control however it doesn't solve our problem of multiple developers changing the same package.

Then they are not checking in their changes

Package in DB should reflect only latest SVN changes.

Anyway, developers shall unit test the changes in the database to minimize need of further rework (and assure package validity) between check out and check in.
For this case, we use separate user/schema for each developer. I see no problem in it.

flyboy, Thats not a bad idea. However can you elaborate on a few things for me.

How do you keep packages consistent between each user/schema?

At the moment because we only have one dev schema, we don't really have any tools to update packages from subversion to oracle. we normally copy the code by handle into a checked out branch somewhere on the file system and the commit it.

What tools do you use? What tools do you recommend using?
How big is your team (is this scalable)?

Thanks, for you help.

Is your shop opposed to checking out and then locking the file? We toyed around with the idea of allowing multiple people to check out the same file, and then merge their changes, but then we decided that would cause more harm than good.

Without checking out & locking a file from Subversion, you'll have to find another in-house methodology for coordinating a change.

- Maybe your PACKAGES are too large, and need to be split out into several smaller PACKAGES, where each person could check out one object at a time?


SQL Developer has a plugin for Subversion, but we haven't had a chance to use it yet.

--=cf

Primarily, when the team is managed well, every developer is responsible for some area and rarely accesses packages "belonging" to other users. It might happen as there are dependencies among them. Conflict handling shall be treated by proper using of any revision control system, which is able to track source code branches made concurrently by developers. The most popular one is CVS, there are many other ones, e.g. the one from anacedent's link. The "file system" alone without this kind of tool is not a good choice for more than one developer.
Each developer may put the most recent package version into his schema everytime he needs. It is very easy for packages - just running the most recent version of all scripts. For other objects (tables, data), it is harder; but as we maintain scripts for their change on customers' sites, we use them for changing each developer's schema as well. Or, after some time, drop the entire schema and create it from baseline. Again, this depends on each developer's need. Well, he easily realizes from revision control system, who made which changes on the part he will be/has been working.