Hi Giulio, I'm curious about how you manage your PL/SQL development and identify packages and its versions and how do you manage concurrency. Until were I know Oracle won't manage concurrency when two developers edit the same package and once broke, the entire package stop working.
I used, in a past project, to ask the team to save packages as text files in the repository and lock them to signalize someone is working on it. The live package being edited should be edited with a different name like "package_name_plus_developers_user_name" so that the package won't be broken for other developers. Once the developer finished to edit the package and make his own tests he would increase its version number (a simple comment in the package interface and body), write a small changelog as a comment, submit it to the repository, release de lock, update package with its real name and delete the temporary one. Sounds a little troublesome, but I couldn't think of a better process. Later I included a version function inside each package so I could check packages versions using an sql script. "It seems they do not want to tag everything in trunk because that would be like a major release (apparently it would include those table and data things). Maybe we could re-organised the code to separate the packages from the data and then we could tag the packages, which is more what they want." Yes, you can have a BTT (branch, tags, trunk) structure for the database DDL including packages, another BTT for documentation and another for source code and manage their evolution separately if it fits better to your team. Instead of one big configuration item now you have 3 to care about. The database definition versions can have patches to update a live database from version a to version b. But anyway you will need to build your high level configuration item, which will represent your entire software package including database, code, documentation etc in its specific compatible version. This set, you can release software. Your installer can check each configuration item version to decide what to do (database version updates, documentation version). There are things that can be just deleted and overwritten (like binaries and help), but database will usually need to be patched. Having the database and plsql code as an independent configuration item sounds good to me. I'm not sure I'm helping... lol Luiz Guilherme M. Kimel -----Mensagem original----- De: Giulio Troccoli [mailto:giulio.trocc...@uk.linedata.com] Enviada em: sexta-feira, 29 de outubro de 2010 10:11 Para: users@subversion.apache.org Assunto: Moving to Subversion for PL-SQL development First of all let me tell you that I don't know much of how PL-SQL development works so I might say something really obvious to you or more likely just wrong. Please forgive me. I have a team that uses StarTeam as their VCS and we are now working on moving the project to Subversion. We are planning to use an importer for the initial load of the repository which seems to do what they want (I'm not looking after that part). I have a problem though with their releasing process. As I understand it, a major release is formed by all the packages and scripts, plus some table initialisation and sometime some data (I presume for defaults and stuff like that). Minor releases are done with patches which included only the packages that have changed from the previous patch. So, if I want 5.4.0 (major release), I get everything. I unpack the kit, install it, run it, whatever it take and I'm done. If I am already on 5.4.0 and I want 5.4.3 (a minor release) I will be sent 3 patches: to 5.4.1, then 5.4.2 and finally 5.4.3. Apparently I just need to unzip them and I'm done. Now, I might not be clear in the above process, so if someone with more experience with PL-SQL development and release wants to correct me, please do. I know there isn't one way to do things, but it's more likely that I understood wrong than we are doing it in a special way. Anyway, if I am right, I'm struggling to come up with a process using Subversion. It seems they do not want to tag everything in trunk because that would be like a major release (apparently it would include those table and data things). Maybe we could re-organised the code to separate the packages from the data and then we could tag the packages, which is more what they want. And this way, to go to 5.4.3 I won't need 5.4.1 and 5.4.2 at all, which in my opinion is even better. In the end what I am looking for with this email is some advice on how to proceed from people with more experience than me in projects using PL-SQL. Thanks Giulio Troccoli Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
