Morning Wendy,
A pretty decent book I never mentioned yesterday is Pragmatic Version
Control With Subversion. It has a chapter on how to integrate third
party code into your repository. Looks pretty useful to me. A couple of
drawbacks though - around what to do when the vendor releases a new
release. However....
We use a packaged product, Banner, to run our Student
Information Systems..it is a huge software package with
thousands of tables and objects. We customize some of
these, and in addition have a number of custom written add
ons. We have a production database and then 4 test
instances that are cloned from the production database.
Typically we have one instance where we are testing and/or
customizing the next release of Banner from the vendor; an
instance where we are doing new development, and one where
we might have production bugs being fixed. All of the
instances use all the same packages, tables, views,
triggers...etc. There are usually multiple programmers
working on each instance, and each programmer usually has
more than one project they are working on within the
instance. Some objects are common to all the projects, like
the student master table, and common code libraries.
Here are my assumptions/observations from the above:
-
You get regular releases of BANNER from the vendor.
-
You customise the code by changing files within the released code,
adding files, and possibly deleting files.
-
At any time after this release, your well oiled teams spring into
action and you have the following work progressing all at the same time:
-
Production - Code is never changed except when fully tested and QA'd
releases arrive via the TEST 4 database systems below.
-
Test 1 - testing the latest BANNER release from the vendor.
-
Test 2 - New development work.
-
Test 3 - Customising the latest BANNER release.
-
Test 4 - Fixing production bugs. (Again?)
-
Teams of multiple developers are working on one or more of the above.
-
Multiple "projects" exists within each development area.
-
You have a lot of common code spread over all these databases.
Ok, dealing with production first. Easy. The code in production is a mix
of the BANNER supplied code, your own deletions, amendments and
additions and should have come through only from the Test 4 system.
Your production code is basically what you will have in trunk.
You need to make sure that no-one trashes trunk and that any commits to
trunk don't break the compile. If they do, the developer responsible
should be "publicly humiliated" 
Test 1 is another easy one. The code drop from the vendor should be
extracted from it's various tar/zip files into a new folder. Once done,
that folder can be imported into the repository as a tag - something
like "Banner release a.b.c.d".
It would be nice if a new release of the vendor code could be extracted
over the top of the last release. This would let Subversion know what
has changed - unfortunately, deleted files would still remain from the
previous release. You CANNOT simply delete a folder and recreate it and
add it back in again. Subversion is not happy when you do that.
"Pragmatic" gives details of a way in which this can be done, but it
relies on a Perl script. I have not looked into this though.
What you could do is have a separate repository for the vendor code
drops. All you do is extract, import into a tag and that' sit. You would
obviously publish the URL of the appropriate tags to the developers so
that they can recreate their development set up in the Test 1 and Test 3
areas.
Test 2 is the biggie, you have all your development work going on here
and various projects within this environment. I assume that the files in
the BANNER release are the ones being used by all projects.
Test 3 looks interesting. I'd set up the system so that the
administrators check out (or export) the latest BANNER release from the
vendor repository and then import it into their own development
repository. This would most likely be on a branch off of trunk (Trunk is
production level code!)
Test 4 is a simple one. Create a branch of trunk and have the developers
work on it by checking out form the branch not from trunk. No-one should
check out the trunk really except maybe the people creating a full code
release (BANNER, your stuff etc) ready for application to production (as
a full release).
There is an alternative way, getting Subversion to create patches to
bring production (trunk) up to a Test 4 branch. Then simply apply the
patches to the running code in production. Either way works.
A repository setup to cover the above might be, and assuming a separate
repository for the BANNER drops:
repos/vendor/banner/releases
Within this repository, you would have tags for each release in a
standard format:
repos/vendor/banner/releases/1.0.0.0
repos/vendor/banner/releases/1.0.1.0
repos/vendor/banner/releases/2.0.0.0
There is no trunk, tags or branches here, simply releases. No work is
ever done here, this repository exists purely to keep safe the code as
originally supplied by the vendors.
Next, a development repository with the "standard" trunk/tags/branches
folders.
repos/banner/trunk
repos/banner/branches
repos/banner/tags
As mentioned above, production code is in trunk and is untouchable!
Branches is where you would create the development stuff by copying
trunk into a development branch with an appropriate name. Your
developers would checkout and work with this branch's code.
Any time a fix is applied to production (in trunk) you can easily merge
that change back into the development branch - if appropriate.
You need, with the above setup, to make sure that the development branch
has a copy of the vendor code appropriate within it, especially if you
are making changes - the last thing you want a developer to do is change
code in the vendor drop repository! The administrator should load up
(import) the vendor drop into the development branch before letting the
hoards of great unwashed developers (!) get access to it. (I consider
myself one of the great unwashed!)
So, how does the above work? Starting from a new code release from the
vendor:
- Unpack the release into a new folder.
mkdir banner_1.2.3.4
cd banner_1.2.3.4
untar ../banner.1.2.3.4_release.tar
- Import into a new "release" in the repos/vendor/banner/releases
repository.
svn import . svn://repos/vendor/banner/releases/1.2.3.4
- Import the same code into a new branch in the main development
repository. This is for the Test 3 area.
svn import . svn://repos/banner/branches/1.2.3.4
-
At this point, you have a safe copy in one repository and a "soon to
be butchered" copy in a new branch of the main repository. No-one knows
about it yet so can't access it. Until you tell them!
-
Advise the Test 3 team that there is a new code drop available for
them to play with, tell them the URL is
svn://repos/banner/branches/1.2.3.4.
They can no check out the new code, as supplied, and begin to apply
changes. As the commit changes, it goes back into the branch just
created for this very purpose. The previous branch still exists and is
still available for bug fixes.
Equally, fixes or changes applied to the previous release can be merged
into this branch - in the event that the same changes are made each time
a new release is made.
- The Test 2 team are eager to get on with their own butchering of the
new release, so when Test 3 are done playing (!), the repository admin
can create a new branch based on the Test 3 team's work so far. This is
a simple enough process:
svn copy svn://repos/banner/branches/1.2.3.4
svn://repos/banner/branches/1.2.3.4_development
Now this is a lazy copy in as much as nothing is actually copied within
the repository, just a note is made that the copy has been made. The
correct files will be checked out when a developer checks out the new
branch.
- Test 2 developers now check out the new development branch:
c:
cd development
mkdir 1.2.3.4
cd 1.2.3.4
svn checkout svn://repos/banner/branches/1.2.3.4_develoment ./
Now all the work that goes on here is committed back into the
development branch and doesn't affect the work done (and possibly
continuing to be done) by Test 3. Any fixes made by Test 3 can be easily
merged into the Test 2 branch as and when required. And indeed, Test 2
work can be merged into Test 3 work too.
I think that will cover it. You may see something I don't, give me a
shout if so.
Ok, all development work is done, and you need to update production.
Easy! You can check the logs for all changes made since the code was
branches and apply those in bulk or in batches as required using the
merge command.
A quick compile and test by test scripts etc, the QA team whatever, and
it's ready to go.
You need a full release of the code now in trunk for a new
customer/database setup, easy, export it:
c:
cd production
mkdir 1.2.3.4
cd 1.2.3.4
svn export svn://repos/banner/trunk ./
You now have all the files in the latest production release with the
original BANNER files modified, added to, deleted or whatever, plus all
changes made by your Test 3 team, the TEST 2 team and so on. All tested
and approved and ready to be run against the database. (Ok, you might
have problems at this point because if the release consists of CREATE
TABLE scripts then you may have those tables already existing!)
If all you want is a patch kit to update a running production system to
the latest 1.2.3.4 release then you would use the svn diff command to
list differences between the current HEAD revision and the original
branch.
I'm not giving an example here because (a) I've never used it and (b) I
can't test it at the moment! Plus I rather suspect this won't be an
option for you.
We need to keep versions of source for the production instance
and each test instance and then be able to merge the test
changes back to production.
Separate branches will facilitate this requirement.
We need to be able to move
individual objects to production as projects and maintenance
are completed.
Easy to do. Simply export when ready and you have a release kit. You can
export an entire project or folder or file within it as you need.
HTH
Cheers,
Norm. [TeamT]
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