Giulio,
I'm not sure if I correctly understood all the details of your questions but
I have been using Subversion in an environment that mostly consists of
C/C++, Java and an Oracle Database for quite some time and would be happy to
share my experience.
From my general perspective managing PL/SQL in a version control system is
quite the same as managing any other sources.
The real complex thing is how to manage and upgrade the different
revisions/version of the database structure itself.
In our environment each "shippable" (alpha, beta, production) version of our
database structure (including PL/SQL) is tagged in Subversion.
The tag contains a snapshot of the scripts (SQL and PL/SQL) needed to create
a new database and additionally contains the appropriate update scripts
(typically a set of SQL Scripts executed in SQL*Plus) needed to update the
last revision to this one.
For an update we then use a custom developed application that determines the
source revision of the database and to witch revision to update, extracts
all the needed tags and executes the appropriate update scripts in each
tagged revision in the proper order.
I hope this helps a little.
Cheers,
Dieter
> -----Original Message-----
> From: Giulio Troccoli [mailto:Giulio.Troccoli_at_uk.linedata.com]
> Sent: Friday, October 29, 2010 15:11
> To: users_at_subversion.apache.org
> Subject: 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
>
>
Received on 2010-10-29 20:07:20 CEST