On second thought

This is adapted from a lengthy answer I gave on StackOverflow to a question as to whether a database should be denormalised for performance reasons. The short answer, I guess, is absolutely not. A more complete short answer would be “Mostly no, but also yes, so you’re going to need two databases. One of them will be normalised, the other not.”

Chris Date, co-creator of the relational model, along with Dr Ted Codd, got tired of misinformed arguments against normalisation and systematically demolished them using scientific method – he got large databases and tested these assertions. I think he wrote it up in Relational Database Writings 1988-1991 but this book was later rolled into edition six of Introduction to Database Systems. This is the definitive text on database theory and design, currently in its eighth edition. Chris Date was an expert in this field when most of us were still running around barefoot.

He found that:

• Some of them hold for special cases
• All of them fail to pay off for general use
• All of them are significantly worse for other special cases

It all comes back to mitigating the size of the working set. Joins involving properly selected keys with correctly set up indexes are cheap, not expensive, because they allow significant pruning of the result before the rows are materialised.

Materialising the result involves bulk disk reads which are the most expensive aspect of the exercise by an order of magnitude. Performing a join, by contrast, logically requires retrieval of only the keys. In practice, not even the key values are fetched: the key hash values are used for join comparisons, mitigating the cost of multi-column joins and radically reducing the cost of joins involving string comparisons. Not only will vastly more fit in cache, there's a lot less disk reading to do.

Moreover, a good optimiser will choose the most restrictive condition and apply it before it performs a join, very effectively leveraging the high selectivity of joins on indexes with high cardinality.

Admittedly this type of optimisation can also be applied to denormalised databases, but the sort of people who want to denormalise a schema typically don't think about cardinality when (if) they set up indexes.

It is important to understand that table scans (examination of every row in a table in the course of producing a join) are rare in practice. The Microsoft SQL Server query optimiser (typical of its class) will choose a table scan only when one or more of the following holds.

• There are fewer than 200 rows in the relation (in this case a scan will be cheaper)
• There are no suitable indexes on the join columns (if it's meaningful to join on these columns then why aren't they indexed? fix it)
• A type coercion is required before the columns can be compared (WTF?! fix it or go home)
• One of the arguments of the comparison is an expression (no index)

Denormalisation is a bet

Performing an operation is more expensive than not performing it. However, performing the wrong operation, being forced into pointless disk I/O and then discarding the dross prior to performing the join you really need, is much more expensive. Even when the "wrong" operation is pre-computed and indexes have been sensibly applied, there remains significant penalty. Denormalising to pre-compute a join – notwithstanding the update anomalies entailed – is a commitment to a particular join. If you need a different join, that commitment is going to cost you big.

If anyone wants to remind me that it's a changing world, I think you'll find that bigger datasets on gruntier hardware just exaggerates the spread of Date's findings.

For all of you who work on billing systems or junk mail generators (shame on you) and are indignantly setting hand to keyboard to tell me that you know for a fact that denormalisation is faster, sorry but you're living in one of the special cases - specifically, the case where you process all of the data, in-order. It's not a general case, and you are justified in your strategy.

You are not justified in falsely generalising it. See the end of the notes section for more information on appropriate use of denormalisation in data warehousing scenarios.

Joins and the Cartesian product

Restrictions are applied as early as possible, most restrictive first. Joins are treated as Cartesian products to which predicates apply only by the query optimiser. This is a symbolic representation (a normalisation, in fact) to facilitate symbolic decomposition so the optimiser can produce all the equivalent transformations and rank them by cost and selectivity so that it can select the best query plan.

The only way you will ever get the optimiser to produce a Cartesian product is to fail to supply a predicate: SELECT * FROM A, B

Joins and indexes

David Aldridge provides some important additional information.

There is indeed a variety of other strategies besides indexes and table scans, and a modern optimiser will cost them all before producing an execution plan. Not every join is based on indexes, and databases have a lot of optimised algorithms and methodologies for joining that are intended to reduce join costs.

I used to be smarter than the MSSQL optimiser. That changed two versions ago. Now it generally teaches me. It is, in a very real sense, an expert system, codifying all the wisdom of many very clever people in a domain sufficiently closed that a rule-based system is effective.

In any case, the cost of a join depends on its type and a few other factors. It needn't be expensive at all - some examples.

• A hash join, in which bulk data is equijoined, is very cheap indeed, and the cost only become significant if the hash table cannot be cached in memory. No index required. Equi-partitioning between the joined data sets can be a great help.
• The cost of a sort-merge join is driven by the cost of the sort rather than the merge -- an index-based access method can virtually eliminate the cost of the sort.
• The cost of a nested loop join on an index is driven by the height of the b-tree index and the access of the table block itself. It's fast, but not suitable for bulk joins.
• A nested loop join based on a cluster is much cheaper, with fewer logical IO'S required per join row -- if the joined tables are both in the same cluster then the join becomes very cheap through the colocation of joined rows.
• Sometimes a table-scan is appropriate. The cut-off for selection of a table-scan join strategy may vary between database engines. It is affected by a number of implementation decisions such as tree-node fill-factor, key-value size and subtleties of algorithm, but broadly speaking high-performance indexing has an execution time of k log n + c. The C term is a fixed overhead mostly made of setup time, and the shape of the curve means you don't get a payoff (compared to a linear search) until n is in the hundreds.

Databases are designed to join, and they're very flexible in how they do it and generally perform very well unless they select the wrong join mechanism.

A practical piece of advice: if it can be used as a foreign key then index it, so that an index strategy is available to the optimiser.

Data warehousing: an appropriate use of denormalisation

Denormalisation is a commitment to a particular join strategy. As mentioned earlier, this interferes with other join strategies. But if you have buckets of disk space, predictable patterns of access, and a tendency to process much or all of it, then pre-computing a join can be very worthwhile.

You can also figure out the access paths your operation typically uses and pre-compute all the joins for those access paths. This is the premise behind data warehouses, or at least it is when they're built by people who know why they're doing what they're doing, and not just for the sake of buzzword compliance.

A properly designed data warehouse is produced periodically by a bulk transformation out of a normalised transaction processing system. This separation of the operations and reporting databases has the very desirable effect of eliminating the clash between OLTP and OLAP (online transaction processing ie data entry, and online analytical processing ie reporting).

An important point here is that apart from the periodic updates, the data warehouse is read only. This renders moot the question of update anomalies.

Don't make the mistake of denormalising your OLTP database (the database on which data entry happens). It might be faster for billing runs but if you do that you will get update anomalies. Ever tried to get Reader's Digest to stop sending you stuff?

Disk space is cheap these days, so knock yourself out. But denormalising is only part of the story for data warehouses. Much bigger performance gains are derived from pre-computed rolled-up values: monthly totals, that sort of thing. It's always about reducing the working set.

Contents

PDF version now available at lulu.com.

Josh Gentry, jgentry@swcp.com
v.1.3, 30 April, 2006

Countless spelling errors corrected by Peter Wone.

Acknowledgments
The following sources where extremely useful:

• Leinwand, Pinsky, and Culpepper. Cisco Router Configuration. Indianapolis, Indiana: Cisco Press, 1998.
• Cisco Systems, Inc., http://www.cisco.com

Disclaimer
This document carries no explicit or implied warranty. Nor is there any guarantee that the information contained in this document is accurate. It is offered in the hopes of helping others, but you use it at your own risk. The author will not be liable for any damages that occur as a result of using this document.

Conventions
Important terms and concepts, when they are introduced, may be displayed in bold. Commands included in the body of the text will be displayed in this font. All names and addresses used in examples are just that, examples, and should not be used on your network. Do not type them in verbatim when configuring your system. Finally, in some examples where the command requires an IP address as an argument, the IP address may be represented in this way, xx.xx.xx.xx, or aa.bb.cc.dd. You will never actually use these strings when configuring your system. They are merely a convention of this document to specify that you should substitute the appropriate IP address at that point.

1. What this document covers

There are several methods available for configuring Cisco routers. It can be done over the network from a TFTP server. It can be done through the menu interface provided at boot up, and it can be done from the menu interface provided by using the command setup. This tutorial does not cover these methods. It covers configuration from the IOS command-line interface only. Useful for anyone new to Cisco routers, and those studying for CCNA.

Note that this tutorial does not cover physically connecting the router to the networks it will be routing for. It covers operating system configuration only.

1.1 Reasons for using the command-line

The main reason for using the command-line interface instead of a menu driven interface is speed. Once you have invested the time to learn the command-line commands, you can perform many operations much more quickly than by using a menu. This is basically true of all command-line vs. menu interfaces. What makes it especially efficient to learn the command-line interface of the Cisco IOS is that it is standard across all Cisco routers. Also, some questions on the CCNA exam require you to know command-line commands.

2. Getting started with Cisco

Initially you will probably configure your router from a terminal. If the router is already configured and at least one port is configured with an IP address, and it has a physical connection to the network, you might be able to telnet to the router and configure it across the network. If it is not already configured, then you will have to directly connect to it with a terminal and a serial cable. With any Windows box you can use HyperTerminal to easily connect to the router. Plug a serial cable into a serial (COM) port on the PC and the other end into the console port on the Cisco router. Start HyperTerminal, tell it which COM port to use and click OK. Set the speed of the connection to 9600 baud and click OK. If the router is not on, turn it on.

If you wish to configure the router from a Linux box, either Seyon or Minicom should work. At least one of them, and maybe both, will come with your Linux distribution.

Often you will need to hit the Enter key to see the prompt from the router. If it is unconfigured it will look like this:

Router>

If it has been previously configured with a hostname, it will look like this:

hostname of router>

If you have just turned on the router, after it boots it will ask you if you wish to begin initial configuration. Say no. If you say yes, it will put you in the menu interface. Say no.

2.1 Modes

The Cisco IOS command-line interface is organized around the idea of modes. You move in and out of several different modes while configuring a router, and which mode you are in determines what commands you can use. Each mode has a set of commands available in that mode, and some of these commands are only available in that mode. In any mode, typing a question mark will display a list of the commands available in that mode.

Router>?

2.2 Unprivileged and privileged modes

When you first connect to the router and provide the password (if necessary), you enter EXEC mode, the first mode in which you can issue commands from the command-line. From here you can use such unprivileged commands as ping, telnet, and rlogin. You can also use some of the show commands to obtain information about the system. In unprivileged mode you use commands like, show version to display the version of the IOS the router is running. Typing show ? will display all the show commands available in the mode you are presently in.

Router>show ?

You must enter privileged mode to configure the router. You do this by using the command enable. Privileged mode will usually be password protected unless the router is unconfigured. You have the option of not password protecting privileged mode, but it is HIGHLY recommended that you do. When you issue the command enable and provide the password, you will enter privileged mode.

To help the user keep track of what mode they are in, the command-line prompt changes each time you enter a different mode. When you switch from unprivileged mode to privileged mode, the prompt changes from:

Router>

to

Router#

This would probably not be a big deal if there were just two modes. There are, in fact, numerous modes, and this feature is probably indispensable. Pay close attention to the prompt at all times.

Within privileged mode there are many sub-modes. In this document I do not closely follow Cisco terminology for this hierarchy of modes. I think that my explanation is clearer, frankly. Cisco describes two modes, unprivileged and privileged, and then a hierarchy of commands used in privileged mode. I reason that it is much clearer to understand if you just consider there to be many sub-modes of privileged mode, which I will also call parent mode. Once you enter privileged mode (parent mode) the prompt ends with a pound sign (#). There are numerous modes you can enter only after entering privileged mode. Each of these modes has a prompt of the form:

Router(arguments)#

They still all end with the pound sign. They are subsumed within privileged mode. Many of these modes have sub-modes of their own. Once you enter privileged mode, you have access to all the configuration information and options the IOS provides, either directly from the parent mode, or from one of its sub modes.

3. Configuring your Cisco Router

If you have just turned on the router, it will be completely unconfigured. If it is already configured, you may want to view its current configuration. Even if it has not been previously configured, you should familiarize yourself with the show commands before beginning to configure the router. Enter privileged mode by issuing the command enable, then issue several show commands to see what they display. Remember, the command show ? will display all the show commands available in the current mode. Definitely try out the following commands:

Router#show interfaces

When you enter privileged mode by using the command enable, you are in the top-level mode of privileged mode, also known in this document as "parent mode." It is in this top-level or parent mode that you can display most of the information about the router. As you now know, you do this with the show commands. Here you can learn the configuration of interfaces and whether they are up or down. You can display what IP protocols are in use, such as dynamic routing protocols. You can view the route and ARP tables, and these are just a few of the more important options.

As you configure the router, you will enter various sub-modes to set options, then return to the parent mode to display the results of your commands. You also return to the parent mode to enter other sub-modes. To return to the parent mode, you hit Ctrl+Z. This puts into effect any commands you have just issued, and returns you to parent mode.

NOTE
I am told by a reliable source that commands take effect immediately and that Ctrl+Z only returns you to the parent mode. - PW

3.1 Global configuration (config)

To configure any feature of the router, you must enter configuration mode. This is the first sub-mode of the parent mode. In the parent mode, you issue the command config.

Router#config

As demonstrated above, the prompt changes to indicate the mode that you are now in.

In configuration mode you can set options that apply system-wide, also referred to as "global configurations." For instance, it is a good idea to name your router so that you can easily identify it. You do this in configuration mode with the hostname command.

Router(config)#hostname ExampleName

As demonstrated above, when you set the name of the host with the hostname command, the prompt immediately changes by replacing Router with ExampleName. (Note: It is a good idea to name your routers with an organized naming scheme.)

Another useful command issued from config mode is the command to designate the DNS server to be used by the router:

ExampleName(config)#ip name-server aa.bb.cc.dd

This is also where you set the password for privileged mode.

ExampleName(config)#enable secret examplepassword

Until you hit ctrl-Z (or type exit until you reach parent mode) your command has not been put into affect. You can enter config mode, issue several different commands, then hit ctrl-Z to activate them all. Each time you hit ctrl-Z you return to parent mode and the prompt:

ExampleName#

Here you use show commands to verify the results of the commands you issued in config mode. To verify the results of the ip name-server command, issue the command show host.

3.2 Configuring Cisco router interfaces

Cisco interface naming is straightforward. Individual interfaces are referred to by this convention:

media type slot#/port#

"Media type" refers to the type of media that the port is an interface for, such as Ethernet, Token Ring, FDDI, serial, etc. Slot numbers are only applicable for routers that provide slots into which you can install modules. These modules contain several ports for a given media. The 7200 series is an example. These modules are even hot-swappable. You can remove a module from a slot and replace it with a different module, without interrupting service provided by the other modules installed in the router. These slots are numbered on the router.

Port number refers to the port in reference to the other ports in that module. Numbering is left-to-right, and all numbering starts at 0, not at one.

For example, a Cisco 7206 is a 7200 series router with six slots. To refer to an interface that is the third port of an Ethernet module installed in the sixth slot, it would be interface Ethernet 6/2. Therefore, to display the configuration of that interface you use the command:

ExampleName#show interface ethernet 6/2

If your router does not have slots, like a 1600, then the interface name consists only of:

media type port#

For example:

ExampleName#show interface serial 0

Here is an example of configuring a serial port with an IP address:

ExampleName#config

Then to verify configuration:

ExampleName#show interface serial 1/1

Note the no shutdown command. An interface may be correctly configured and physically connected, yet be "administratively down." In this state it will not function. The command for causing an interface to be administratively down is shutdown.

ExampleName(config)#interface serial 1/1

In the Cisco IOS, the way to reverse or delete the results of any command is to simply put no in front of it. For instance, if we wanted to unassign the IP address we had assigned to interface serial 1/1:

ExampleName(config)#interface serial 1/1

Configuring most interfaces for LAN connections might consist only of assigning a network layer address and making sure the interface is not administratively shutdown. It is usually not necessary to stipulate data-link layer encapsulation. Note that it is often necessary to stipulate the appropriate data-link layer encapsulation for WAN connections, such as frame-relay and ATM. Serial interfaces default to using HDLC. A discussion of data-link protocols is outside the scope of this document. You will need to look up the IOS command encapsulation for more details.

3.3 Configuring Cisco Routing

IP routing is automatically enabled on Cisco routers. If it has been previously disabled on your router, you turn it back on in config mode with the command ip routing.

ExampleName(config)#ip routing

There are two main ways a router knows where to send packets. The administrator can assign static routes, or the router can learn routes by employing a dynamic routing protocol.

These days static routes are generally used in very simple networks or in particular cases that necessitate their use. To create a static route, the administrator tells the router operating system that any network traffic destined for a specified network layer address should be forwarded to a similarly specified network layer address. In the Cisco IOS this is done with the ip route command.

ExampleName

#config

Two things to be said about this example. First, the packet destination address must include the subnet mask for that destination network. Second, the address it is to be forwarded to is the specified address of the next router along the path to the destination. This is the most common way of setting up a static route, and the only one this document covers. Be aware, however, that there are other methods.

Dynamic routing protocols, running on connected routers, enable those routers to share routing information. This enables routers to learn the routes available to them. The advantage of this method is that routers are able to adjust to changes in network topologies. If a route is physically removed, or a neighbour router goes down, the routing protocol searches for a new route. Routing protocols can even dynamically choose between possible routes based on variables such as network congestion or network reliability.

There are many different routing protocols, and they all use different variables, known as "metrics," to decide upon appropriate routes. Unfortunately, a router needs to be running the same routing protocols as its neighbours. Many routers can, however, run multiple protocols. Also, many protocols are designed to be able to pass routing information to other routing protocols. This is called "redistribution." The author has no experience with trying to make redistribution work. There is an IOS redistribute command you can research if you think this is something you need. This document's companion case study describes an alternative method to deal with different routing protocols in some circumstances.

Routing protocols are a complex topic and this document contains only this superficial description of them. There is much to learn about them, and there are many sources of information about them available. An excellent source of information on this topic is Cisco's website, http://www.cisco.com.

This document describes how to configure the Routing Information Protocol (RIP) on Cisco routers. From the command-line, we must explicitly tell the router which protocol to use, and what networks the protocol will route for.

ExampleName#config

Now when you issue the show ip protocols command, you should see an entry describing RIP configuration.

3.4 Saving your Cisco Router configuration

Once you have configured routing on the router, and you have configured individual interfaces, your router should be capable of routing traffic. Give it a few moments to talk to its neighbours, then issue the commands show ip route and show ip arp. There should now be entries in these tables learned from the routing protocol.

If you turned the router off right now, and turned it on again, you would have to start configuration over again. Your running configuration is not saved to any permanent storage media. You can see this configuration with the command show running-config.

ExampleName#show running-config

You do want to save your successful running configuration. Issue the command copy running-config startup-config.

ExampleName#copy running-config startup-config

Your configuration is now saved to non-volatile RAM (NVRAM). Issue the command show startup-config.

ExampleName#show startup-config

Now any time you need to return your router to that configuration, issue the command copy startup-config running-config.

ExampleName#

copy startup-config running-config

3.5 Example Cisco Router configuration

1. Router>enable

2. Router#config

3. Router(config)#hostname N115-7206

4. N115-7206(config)#interface serial 1/1

5. N115-7206(config-if)ip address 192.168.155.2 255.255.255.0

6. N115-7206(config-if)no shutdown

7. N115-7206(config-if)ctrl-z

8. N115-7206#show interface serial 1/1

9. N115-7206#config

10. N115-7206(config)#interface ethernet 2/3

11. N115-7206(config-if)#ip address 192.168.150.90 255.255.255.0

12. N115-7206(config-if)#no shutdown

13. N115-7206(config-if)#ctrl-z

14. N115-7206#show interface ethernet 2/3

15. N115-7206#config

16. N115-7206(config)#router rip

17. N115-7206(config-router)#network 192.168.155.0

18. N115-7206(config-router)#network 192.168.150.0

19. N115-7206(config-router)#ctrl-z

20. N115-7206#show ip protocols

21. N115-7206#ping 192.168.150.1

22. N115-7206#config

23. N115-7206(config)#ip name-server 172.16.0.10

24. N115-7206(config)#ctrl-z

25. N115-7206#ping archie.au

26. N115-7206#config

27. N115-7206(config)#enable secret password

28. N115-7206(config)#ctrl-z

29. N115-7206#copy running-config startup-config

30. N115-7206#exit

4. Troubleshooting your Cisco router

Inevitably, there will be problems. Usually, it will come in the form of a user notifying you that they can not reach a certain destination, or any destination at all. You will need to be able to check how the router is attempting to route traffic, and you must be able to track down the point of failure.

You are already familiar with the show commands, both specific commands and how to learn what other show commands are available. Some of the most basic, most useful commands you will use for troubleshooting are:

ExampleName#show interfaces

4.1 Testing connectivity

It is very possible that the point of failure is not in your router configuration, or at your router at all. If you examine your router's configuration and operation and everything looks good, the problem might be be farther up the line. In fact, it may be the line itself, or it could be another router, which may or may not be under your administration.

One extremely useful and simple diagnostic tool is the ping command. Ping is an implementation of the IP Message Control Protocol (ICMP). Ping sends an ICMP echo request to a destination IP address. If the destination machine receives the request, it responds with an ICMP echo response. This is a very simple exchange that consists of:

Hello, are you alive?

Yes, I am.

ExampleName#ping xx.xx.xx.xx

If the ping test is successful, you know that the destination you are having difficulty reaching is alive and physically reachable.

If there are routers between your router and the destination you are having difficulty reaching, the problem might be at one of the other routers. Even if you ping a router and it responds, it might have other interfaces that are down, its routing table may be corrupted, or any number of other problems may exist.

To see where packets that leave your router for a particular destination go, and how far, use the trace command.

ExampleName#trace xx.xx.xx.xx

It may take a few minutes for this utility to finish, so give it some time. It will display a list of all the hops it makes on the way to the destination.

4.2 debug commands

There are several debug commands provided by the IOS. These commands are not covered here. Refer to the Cisco website for more information.

4.3 Hardware and physical connections

Do not

overlook the possibility that the point of failure is a hardware or physical connection failure. Any number of things can go wrong, from board failures to cut cables to power failures. This document will not describe troubleshooting these problems, except for these simple things.

Check to see that the router is turned on. Also make sure that no cables are loose or damaged. Finally, make sure cables are plugged into the correct ports. Beyond this simple advice you will need to check other sources.

4.4 Out of your control

If the point of failure is farther up the line, the problem might lie with equipment not under your administration. Your only option might be to contact the equipment's administrator, notify them of your problem, and ask them for help. It is in your interest to be courteous and respectful. The other administrator has their own problems, their own workload and their own priorities. Their agenda might even directly conflict with yours, such as their intention to change dynamic routing protocols, etc. You must work with them, even if the situation is frustrating. Alienating someone with the power to block important routes to your network is not a good idea.

5. References

• Leinwand, Pinsky and Culpepper Cisco Router Configuration. Indianapolis, Indiana: Cisco Press, 1998.
• Cisco Systems, Inc., http://www.cisco.com

The rules are informally stated as

1. Round work periods up to whole multiple of 15 minutes.
2. Round rest periods down to whole multiple of 15 minutes.
3. At least six hours continuous rest in any 24 hour period.
4. At most six hours continuous work.
5. No more than 14 hours total work in any 24 hour period.
6. For fatigue management certified companies, (5) amends to:
   1. No more than 28 hours total work in any 48 hour period.
   2. No more than 16 hours total work in any 24 hour period.
7. Over a 14 day period no more than 154 hours work.
8. In any 14 day period there must be two 24 hour rest periods.
9. Over a 28 day period no more than 288 hours work.

These rules may be restated for evaluation against a database:

For each period of work (PW), check whether PW exceeds 6 hours.

For each period of rest (PR_n) that is at least 6 hours in length, check whether the interval between the start of PR_n and the start of PR_n+1 exceeds 24 hours.

For each period of work (PW), get all periods of work that begin in the 24 hour period starting at the beginning of PW and sum the durations, truncating to 24 hours from the start of PW. Check whether the value exceeds 14.

For each period of work (PW), get all periods of work that begin in the 48 hour period starting at the beginning of PW and sum the durations, truncating to 48 hours from the start of PW. Check whether the value exceeds 28.

For each period of work (PW), get all periods of work that begin in the 24 hour period starting at the beginning of PW and sum the durations, truncating to 24 hours from the start of PW. Check whether the value exceeds 16.

The grass is riz, I wonder where the birdies is! My capsicums haven’t grown much. I expect this is because they are too busy fruiting.

As you can see, growth is rampant.

Plants too!

PATH

A path to a temporary file which contains all the paths for which the operation was started. Each path is on a separate line in the temp file.

DEPTH

The depth with which the commit/update is done.

Possible values are:

-2

svn_depth_unknown

-1

svn_depth_exclude

0

svn_depth_empty

1

svn_depth_files

2

svn_depth_immediates

3

svn_depth_infinity

MESSAGEFILE

Path to a file containing the log message for the commit. The file contains the text in UTF-8 encoding. After successful execution of the start-commit hook, the log message is read back, giving the hook a chance to modify it.

REVISION

The repository revision to which the update should be done or after a commit completes.

ERROR

Path to a file containing the error message. If there was no error, the file will be empty.

CWD

The current working directory with which the script is run. This is set to the common root directory of all affected paths.

Note that although we have given these parameters names for convenience, you do not have to refer to those names in the hook settings. All parameters listed for a particular hook are always passed, whether you want them or not ;-)

If you want the Subversion operation to hold off until the hook has completed, check Wait for the script to finish.

Normally you will want to hide ugly DOS boxes when the script runs, so Hide the script while running is checked by default.

Sample client hook scripts can be found in the contrib folder in the TortoiseSVN repository . (Section 3, “TortoiseSVN is free!” explains how to access the repository).