RE: How do I mark a file as run once?

 Thanks Andrew. I don't think we can use the order number in the script name, for othe reasons, but using a property to keep track of promotion status will definately be investigated, as will redflagging any previously committed sql. I think we'll have to keep the old tracking system, but in a reduced capacity.

Luke

-----Original Message-----
From: Reedick, Andrew [mailto:jr9445_at_ATT.COM]
Sent: Saturday, 23 February 2008 1:26
To: Luke Mason; users_at_subversion.tigris.org
Subject: RE: How do I mark a file as run once?

> From: Luke Mason [mailto:lmason_at_oasisasset.com.au]
> Sent: Thursday, February 21, 2008 11:58 PM
> To: users_at_subversion.tigris.org
> Subject: How do I mark a file as run once?
>
> Hi All,
> 
> We have certain files that can only be applied once to an environment.  
> Mostly database table scripts like create table, alter table, some
> inserts that fill with default data, etc.  Using PVCS, we use
> promotion groups to manage this.  If/when we move to subversion, how
> would we manage this?
> 
> Also,  we manually list all the files required for a change in a
> tracking system.  This allows us to set an apply order - you want to
> create the table before you attempt to insert data into it, or maybe
> alter it before you update it.  If SVN doesn't require us to keep the
> list of files, because the atomic commits are an intrinisic changeset,
> (something we're looking forward to) how do we maintain this apply
> order?  DO we have to keep the manual list of files, but just the
> database changes, not every file in the change?
 

Put the order number in the script name:
        01_create_table.sql
        02_alter_table.sql
        03_tweak_data.sql
And have your deployment script simply run them in order. Simple and easy (just make sure to use leading zero's to maintain the sort order.)

As for promotion groups, you could maybe possibly kinda use properties to flag what's been deployed. Personally, I would either track it externally, or maintain a checked-in file that lists what scripts have already been run for that environment. You can also look at revision numbers and only deploy .sql files in the new revisions. Ex: if the last build would rev 100, and today's build is rev 120, you would only run/deploy any scripts added in revisions 101-120. If you tag each build, you could also diff the sql dir between tags to find the new .sql files. (You will want to raise a red flag if a previously deployed .sql file is modified.)

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email ______________________________________________________________________

"This email is intended for the named recipient only. The information contained in this message may be confidential, or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of this email, disclose its contents to any other party, or take any action in reliance on it, or in reference to it. If you have received this email in error, would you please contact the sender immediately and delete/destroy all copies of this message, both electronic and otherwise. It is the recipient's duty to virus scan and otherwise test the enclosed information before using the information or loading attached files onto any computer system. Oasis Asset Management Ltd does not warrant that the information contained in this e-mail is free from viruses, defects, errors, interception or interference. Any views expressed in this message are those of the individual sender, except where that sender specifically states them to be the views of Oasis Asset Management Ltd."

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-25 05:21:55 CET