RE: Source Control for DB objects
- From: Jeff Chirco <JChirco@xxxxxxxxxx>
- To: "Dunbar, Norman (Capgemini)" <norman.dunbar.capgemini@xxxxxxxxxxxxxxxxxxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 10 Aug 2011 04:02:04 +0000
Thanks Norm for this great explanation. I think I understand what you are
saying and it sounds like a pretty good idea, I just need to do some more
reading on subversion. One thing, is it common to create a new repository for
say each schema in the database? Or should I just create one repository per
database? We write all our own custom applications and they all share the same
database.
Thanks,
Jeff
-----Original Message-----
From: Dunbar, Norman (Capgemini)
[mailto:norman.dunbar.capgemini@xxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, August 05, 2011 12:03 PM
To: Jeff Chirco; oracle-l@xxxxxxxxxxxxx
Subject: RE: Source Control for DB objects
Evening Jeff,
>> Say user A is working on a package and then user B needs to finish
working
>> on the package where A left off. Is the only way user B can get user
A's
>> changes is if he commits/ check in his changes? But it is not in
production
>> yet so how can I tell what version is in production. Currently I
only have
>> my developers check in their source when it has been moved to
production,
>> that way it is very easy for me to tell what is in production.
Your production code is not necessarily In the same repository as your
development (or QA) code. Try this instead:
Your dev users will work on the code until it is complete. When done and
tested, it is all committed back to the development repository.
The repo-admin may well decide to tag off a copy of the repository at this
point. This doesn't create a copy inside and thus duplicate the files, it
simply makes a note of what version each file that has been tagged is at.
This tagged "copy" can then be exported from the repository, say into QA.
The QA team install the code, in the normal "release" manner, and get to work
hammering it silly with regression scripts etc. If all is well, they pass the
"ok" back to repo admin. Otherwise, it has to go back to the developers. The
tagged "copy" can be deleted. (But need not be.)
Repeat as necessary until QA are happy.
The code is now fit for production. So the repo-admin tags again, this time he
marks it as a release.
The release is again, not a "copy" physically, just a note inside the
repository.
The release is exported again, and installed into production. Users are happy.
Now, while all this tagging is going on, the developers can still be making
changes without affecting the tagging etc. :-)
In your case where A is part finished a package before his holiday, then at
that point, it is allowed for him to commit an unfinished change.
Provided he marks his commit comments as such - "BROKEN COMMIT. I'm on holiday,
this will not compile." or something.
User B now updates her working copy and gets User A's "broken", half finished
code. Carries on and finished A's work.
I do this frequently. Not quite as above. I write Open Source docs for the
Firebird (www.firebirdsql.org) database. I do this on my laptop and also on my
home desktop. I keep my repository on a USB stick. If I am away and do some
work on my laptop, I Commit "broken" files back to the repository every night.
If I work on the desktop, I can do likewise.
At any time, I can always be sure that a quick "update" will get me exactly
back to where I was "last time". I flag all my broken commits with a message
like "UNFINISHED: better description goes here". When I look at the log, I can
see all the broken stuff.
Simple?
Cheers,
Norm.
Norman Dunbar
Contract Senior Oracle DBA
Capgemini Database Team (EA)
Internal : 7 28 2051
External : 0113 231 2051
Information in this message may be confidential and may be legally privileged.
If you have received this message by mistake, please notify the sender
immediately, delete it and do not copy it to anyone else.
We have checked this email and its attachments for viruses. But you should
still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under
the Freedom of Information Act, Data Protection Act or for litigation. Email
messages and attachments sent to or from any Environment Agency address may
also be accessed by someone other than the sender or recipient, for business
purposes.
If we have sent you information and you wish to use it please read our terms
and conditions which you can get by calling us on 08708 506 506. Find out more
about the Environment Agency at www.environment-agency.gov.uk
--
//www.freelists.org/webpage/oracle-l
Other related posts:
