--- a/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita	Wed Mar 31 11:11:55 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B.dita	Fri Jun 11 12:39:03 2010 +0100
@@ -1,52 +1,52 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B" xml:lang="en"><title>Introduction
-to Transactions</title><shortdesc>A transaction is a series of operations on a store, normally completed
-by committing them using the store's <codeph>CommitL()</codeph> function. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>Transactions are supported by the commit and revert protocol. The series
-of operations forming a transaction must all succeed for the transaction to
-be successful. </p>
-<p>If a leave occurs during an operation on the store during a transaction,
-or if the store's <codeph>RevertL()</codeph> function is called explicitly,
-the transaction is reverted. This facility parallels the commit and rollback
-functions which are conventional in databases. However, reverting is not quite
-the same as rolling back; integrity of data is guaranteed, but some indexes
-may be corrupted. </p>
-<p>The commit and revert protocol is useful for ensuring that persistent data
-moves from one consistent state to another and for guaranteeing the integrity
-of persistent store data in the event of failures. </p>
-<p>Typically, changes to a store are not made permanent until they are committed,
-establishing what is called a commit point. Until such changes are committed,
-they can be rolled back or reverted, effectively causing the store to revert
-back to its state before the changes were made. If a process termination or
-a media failure occurs, the store reverts automatically to its state at the
-last successful commit point. </p>
-<p>In permanent file stores the protocol applies to: </p>
-<ul>
-<li id="GUID-F16D4A25-8103-563C-9DC5-D79F7C275ACB"><p>generating new streams </p> </li>
-<li id="GUID-A0EA4352-D06B-59D3-9E04-D0B42131AF5B"><p>deleting streams </p> </li>
-<li id="GUID-83307858-E18D-5F78-8E30-F6754EB6926E"><p>creating new streams </p> </li>
-<li id="GUID-FAD15660-6405-5C11-A72D-40471D5FE2E5"><p>replacing streams </p> </li>
-<li id="GUID-A00822E2-2FE7-55CA-9144-7B9F6DA7C3F7"><p>setting the root stream </p> </li>
-</ul>
-<p>The protocol also applies to creating new streams or replacing existing
-streams in dictionary stores. </p>
-<p>The protocol does<i> not</i> apply to overwriting existing streams. </p>
-<p>The following diagram shows the idea: </p>
-<fig id="GUID-9F093A25-C9C6-5590-9427-EBC4BD26AC73">
-<title>Transaction Commit and Revert</title>
-<image href="GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e361851_href.png" placement="inline"/>
-</fig>
-</conbody><related-links>
-<link href="GUID-79F39C97-75E8-5DB1-B976-8FE76E6E60C9.dita"><linktext>Dictionary
-stores</linktext></link>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-D4001895-09B9-5A47-BEE7-648FAB55F85B" xml:lang="en"><title>Introduction
+to Transactions</title><shortdesc>A transaction is a series of operations on a store, normally completed
+by committing them using the store's <codeph>CommitL()</codeph> function. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Transactions are supported by the commit and revert protocol. The series
+of operations forming a transaction must all succeed for the transaction to
+be successful. </p>
+<p>If a leave occurs during an operation on the store during a transaction,
+or if the store's <codeph>RevertL()</codeph> function is called explicitly,
+the transaction is reverted. This facility parallels the commit and rollback
+functions which are conventional in databases. However, reverting is not quite
+the same as rolling back; integrity of data is guaranteed, but some indexes
+may be corrupted. </p>
+<p>The commit and revert protocol is useful for ensuring that persistent data
+moves from one consistent state to another and for guaranteeing the integrity
+of persistent store data in the event of failures. </p>
+<p>Typically, changes to a store are not made permanent until they are committed,
+establishing what is called a commit point. Until such changes are committed,
+they can be rolled back or reverted, effectively causing the store to revert
+back to its state before the changes were made. If a process termination or
+a media failure occurs, the store reverts automatically to its state at the
+last successful commit point. </p>
+<p>In permanent file stores the protocol applies to: </p>
+<ul>
+<li id="GUID-F16D4A25-8103-563C-9DC5-D79F7C275ACB"><p>generating new streams </p> </li>
+<li id="GUID-A0EA4352-D06B-59D3-9E04-D0B42131AF5B"><p>deleting streams </p> </li>
+<li id="GUID-83307858-E18D-5F78-8E30-F6754EB6926E"><p>creating new streams </p> </li>
+<li id="GUID-FAD15660-6405-5C11-A72D-40471D5FE2E5"><p>replacing streams </p> </li>
+<li id="GUID-A00822E2-2FE7-55CA-9144-7B9F6DA7C3F7"><p>setting the root stream </p> </li>
+</ul>
+<p>The protocol also applies to creating new streams or replacing existing
+streams in dictionary stores. </p>
+<p>The protocol does<i> not</i> apply to overwriting existing streams. </p>
+<p>The following diagram shows the idea: </p>
+<fig id="GUID-9F093A25-C9C6-5590-9427-EBC4BD26AC73">
+<title>Transaction Commit and Revert</title>
+<image href="GUID-6FC62A2F-E27F-54A8-A97F-0F42426D1F63_d0e355771_href.png" placement="inline"/>
+</fig>
+</conbody><related-links>
+<link href="GUID-79F39C97-75E8-5DB1-B976-8FE76E6E60C9.dita"><linktext>Dictionary
+stores</linktext></link>
 </related-links></concept>
\ No newline at end of file