You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Luke Mason <lm...@oasisasset.com.au> on 2008/02/22 04:57:57 UTC
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?
Luke Mason
Configuration Specialist
Oasis Asset Management Limited
Ground Floor, 65-67 Burelli Street
WOLLONGONG NSW 2500
Telephone:
61 2 4231 3086
Facsimile:
61 2 4231 3005
Email:
lmason@oasisasset.com.au <ma...@oasisasset.com.au>
Website:
www.oasisasset.com.au <http://www.oasisasset.com.au/>
"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
______________________________________________________________________
RE: How do I mark a file as run once?
Posted by Luke Mason <lm...@oasisasset.com.au>.
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@ATT.COM]
Sent: Saturday, 23 February 2008 1:26
To: Luke Mason; users@subversion.tigris.org
Subject: RE: How do I mark a file as run once?
> From: Luke Mason [mailto:lmason@oasisasset.com.au]
> Sent: Thursday, February 21, 2008 11:58 PM
> To: users@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: How do I mark a file as run once?
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> From: Luke Mason [mailto:lmason@oasisasset.com.au]
> Sent: Thursday, February 21, 2008 11:58 PM
> To: users@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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How do I mark a file as run once?
Posted by Geoffrey <li...@serioustechnology.com>.
Luke Mason wrote:
> 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?
This sounds like a job for make or some small scripts. This really
isn't in the scope of a source/version code control system.
--
Until later, Geoffrey
Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How do I mark a file as run once?
Posted by Les Mikesell <le...@gmail.com>.
Luke Mason wrote:
> 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?
In general you should move the knowledge of what to do for an install or
update into scripts that you run after checkout/update with the script
itself doing the check for the existing database contents and then
executing the appropriate create/alter/insert commands to make it
current. That way the same procedure will work even if you export the
files and copy them elsewhere to run instead of using a working copy,
and running it more than once is non-destructive. But you might want to
have an option in the script to blow the old database contents away so
you can start over easily after you are done testing.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How do I mark a file as run once?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Feb 21, 2008, at 22:57, Luke Mason wrote:
> 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?
I'm not familiar with PVCS but this seems outside the scope of a
reversion control system. Subversion does not run any scripts for
you. It just lets you manage a filesystem with history. In other
words, there's nothing in Subversion to do specifically what you ask.
You could invent a new property "run-once" and set it to true on
those file that you only want to run once. Then write your script-
runner so that it checks that property before running a script.
> 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?
You can get the list of files changed by a revision if that would
help you, for example using "svn diff --summarize $REPO -r $REV"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: How do I mark a file as run once?
Posted by Hari Kodungallur <hk...@gmail.com>.
On Thu, Feb 21, 2008 at 8:57 PM, Luke Mason <lm...@oasisasset.com.au>
wrote:
> 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?
>
Subversion certainly does not have any of these that you are asking. These
kind of things should be not be done by a source version control system
anyway.
You should write scripts to accomplish these. For example, your script can
check if the database exists and then accordingly invoke the script if it
does not.
Thanks,
-Hari