This webinar is led by WANdisco’s Chief Architect of Big Data, Dr. Konstantin Shvachko, and Jagane Sundar, our Chief Technology Officer and Vice President of Engineering for Big Data. Jagane and Konstantin were part of the original Apache Hadoop team, and have unparalleled expertise in Big Data.
This 30 minute webinar replay covers:
The cross-industry growth of Hadoop in the enterprise.
The new “Active-Active Architecture” for Apache Hadoop that improves performance.
Solving the fundamental issues of Hadoop: usability, high availability, HDFS’s single-point of failure and disaster recovery.
How WANdisco’s active-active replication technology will alleviate these issues by adding high-availability, data replication and data security to Hadoop, taking a fundamentally different approach to Big Data.
You can watch the full ‘The Future of Big Data for the Enterprise’ replay, along with our other webinars, at our Webinar Replays page.
Hook scripts are executable programs that Apache Subversion users can configure to be triggered by a specific repository event.
When you install Subversion, a ‘hook’ directory is created automatically that contains templates of all the available hook scripts. These .tmpl files contain info about that particular hook script, alongside details on the data that’s passed from Subversion when the hook script is executed.
One hook script is the pre-commit hook script, which executes when a commit transaction happens, but before any changes are applied to the repository. With pre-commit hook scripts, Subversion passes two pieces of information to the hook script: the name of the repository and a uniquely generated name or code for the transaction being committed.
A Basic Pre-Commit Hook Script
Hook scripts work by either exiting with a ‘0,’ which allows the transaction to happen, or by exiting with a ‘1’ which blocks all commits. In this basic example, we’ll show how the ‘exit 1’ command can be used to prevent all transactions.
Locate the pre-commit hook script in the hook directory.
Open the file and replace the text with:
This will block all commits, from all users. When you try and commit, you should see a similar message to the one below:
Need more info?
A free replay of our ‘All About Hook Scripts’ webinar is available now. This webinar offers further examples of hook scripts, including start-commit, pre-revproper-change, and pre- and post-lock hook scripts.
Branching and merging is a contentious issue for the Subversion community, with even the most experienced Subversion users sometimes needing extra guidance on how best to manage their branches. In our latest webinar, Michael Lester, WANdisco’s Director of Training, provided an introduction to branching and merging which ranged from the basic, ‘what is a branch?’ question, to the different development models open to Subversion users, and advice on managing deleted branches.
Essentially, a branch is a line of development that exists independently of another line. Branches allow developers to work on code independently of the work going on in the trunk. No changes made within a branch are seen by people working in the trunk, or in any other branches. There’s no real limit on the number of branches that can be created, but there are some general development models for branching that Michael addressed in the webinar:
1) “Branching Nothing” Development Model
In this model, all of the development is done within the trunk. In ideal circumstances, all of the checkouts and commits will be in line, and no-one will check out the same thing at the same time, but it’s likely there will eventually be a situation where multiple people checkout the same code simultaneously, and then it becomes a race to see who can make their commit first. The second person to make their commit will receive a message alerting them that their commit has failed, and that they must update their working copy.
‘Updating the working copy’ takes the differences between what was checked out and edited, and what the other person has modified, and applies it to the working files. In the best case scenario, this is a straightforward update, but in some cases it can create a conflict situation.
The branching nothing model can create ‘update hesitation,’ where the developers are aware that performing a commit could force them to go back and deal with other peoples’ changes – a potentially time-consuming and annoying process! – which encourages them to wait until the last minute to make their commit. The branching nothing development model tends to get more complicated, the more people who are working on the same code, at the same time.
2) “Branch Everything” Development Model
With this development model, every change within a project is given its own branch; either a ‘bug branch’ or an ‘enhancement branch.’ People are assigned to work on a particular branch, and these branches are then merged into the trunk. This has a number of advantages:
All work is isolated. You don’t have to worry about other changes interfering with yours until the merge happens.
All work is scheduled. There is a defined branch for everything that needs to be worked on.
All work is branched from a stable trunk revision.
Small, independent merges mean it’s usually easier to resolve changes.
However, there are also some disadvantages to this development model:
Lots of branches.
Lots of merges.
A lot of overhead for some very straightforward fixes, e.g the misspelling of a word, or a column heading not being centered.
3) “Branch Big Things” Development Model
With this development model, every task is divided into one of two categories:
A small development effort – worked on directly in the trunk, with no branching or merging required!
A big development effort – tasks such as a complicated bug or enhancement are given their own branch.
This categorisation is based on:
Relationship to other bugs / enhancements – is the change likely to impact any other code?
How much testing is required? – some changes may require virtually no testing (e.g correcting a misspelt word) but other times you will literally have to do system-level testing to ensure the changes haven’t had any unforeseen negative effects.
How long will the bug/enhancement take?
Deleting Branches & Finding Deleted Branches
Regardless of whether you branch everything, or follow the ‘branch big things’ development model, if you’re going to branch, then at some point you’ll have to delete some of the old branches. Deleting branches is simply a matter of:
1) Go to the repo browser.
2) Right click on the branch you want to delete.
3) Select the delete command.
Remember that when you delete a branch, it gets deleted from the revision folder but not from the repository. You can always go back to an earlier revision to see how the branch looked, and have the option of exporting the code from the deleted branch, or recovering the branch and recreating it in a later revision.
To make it easier to locate a deleted branch, it is a often a good idea to write something in the log message upon deleting that branch. Another good idea, is to create a ‘deleted branch’ folder, where you can store branches that you no longer need.