Trunk, Branch & Tags

in SVN the directory names themselves mean nothing -- "trunk, branches and tags" are simply a common convention that is used by most repositories. Not all projects use all of the directories (it's reasonably common not to use "tags" at all), and in fact, nothing is stopping you from calling them anything you'd like, though breaking convention is often confusing.

I'll describe probably the most common usage scenario of branches and tags, and give an example scenario of how they are used.

• Trunk: The main development area. This is where your next major release of the code lives, and generally has all the newest features.
• Branches: Every time you release a major version, it gets a branch created. This allows you to do bug fixes and make a new release without having to release the newest - possibly unfinished or untested - features.
• Tags: Every time you release a version (final release, release candidates (RC), and betas) you make a tag

Release Management

1) What factors influence the opening of a feature branch?

Typically, feature branches are created in cases where the new feature or enhancement has broad-sweeping changes to the code base such that introducing them in the trunk may be too disruptive. Also, feature branches may be used for prototyping or proof-of-concept for code that may never end up in trunk.

2) What is the purpose of continuous integration for a development team?

The primary purpose of CI is to provide regular, fast feedback to developers as they commit changes to the shared code repository (VCS). The idea being that we’re always integrating our code on commit, so that when conflicts arise, they can be addressed more quickly and easily than if the changes had been made days, week, or even months ago.

Views

Views in a nutshell

• virtual table
• based on 1 or more tables or views
• takes no storage space other than the definition of the view in the DD
• contains no data
• provides additional level of security
• hides implementation complexity
• lets you change the data you can access, applying operators, aggregation functions, filters etc. on the base table.
• isolates application from changes
• An updatable view allows you to insert, update, and delete rows by propagating the changes to the base table
• The data dictionary views ALL_UPDATABLE_COLUMNS indicate which view columns are updatable.
• Views which are not updatable can be modified using INSTEAD OF trigger.
• can be replaced with a CREATE OR REPLACE VIEW statement. The REPLACE option updates the current view definition but preserves the present security authorizations.
• lets you reorder columns easily with a CREATE OR REPLACE rather than going into a messy drop column for the base table with data
• The underlying SQL definition of the view can be read via select text from user_views for the view.
• Oracle does not enforce constraints on views. Instead, views are subject to the constraints of their base tables.