DOCSLIB.ORG

How to Work with Mercurial

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
How to Work with Mercurial How to Work with Mercurial Author: Sjoerd Mullender Organization: CWI, MonetDB B.V. Abstract The MonetDB repository has moved from CVS on Sourceforge to Mercurial on dev.monetdb.org. In this document, we give an introduction to the use of Mercurial, specifically for MonetDB. Introduction A nice tutorial about how to use Mercurial, aimed at Subversion (SVN) users (although CVS users will understand the Subversion references fine) can be found at http://hginit.com/. There is also a Mercurial book. You can read it online at http://hgbook.red-bean.com/. The main website for Mercurial is https://www.mercurial-scm.org/. There is also a lot of information there, including information about all sorts of nifty extensions. The Basics Mercurial (and git, for that matter) work around the concept of changesets where both CVS and SVN work around the concept of revisions. A revision is basically what the project (or a particular file in the case of CVS) looks like at any particular point in time. A changeset is basically a set of changes. Both CVS and SVN are centralized systems where there is one "truth", the central repository, and every developer has one particular revision on their disk (usually the latest). When you make a change, you upload the new version to the server (known as commit). If another developer was there first, the commit fails. You first need to update your own copy from the central repository, merging any changes in the process, and, when that was successful, try the commit again. Mercurial works differently. Every developer has a complete copy (a clone) of the repository on their disk. When you make a change, you can commit it to your local copy of the repository, independently of any other developers. Since this work is independent of others, you can commit smaller changes that are not yet finished and that do not yet work. When you are satisfied with the changes, you can share them with others by pushing the changes to the central repository. Before you push changes, you may first have to pull in changes from others that had already been pushed by them. Pushing and pulling are mirror operations. What they do is compare the collections of changes (the changesets) in the originating and destination repositories, and copy over all changes that are in the originating repository but not yet in the destination. After you pull in changes, you need to update your working files. In the process you may have to resolve conflicting changes. Because every developer has their own copy of the repository, and every developer makes changes and gets other developers' changes in a different order, the histories of different copies of the repository are different. You can see that in the log of the repository. In Mercurial, changesets are identified by two numbers. A relatively small number that is easy to use (the local revision number), and a large, hexadecimal number (the global revision id). The local revision number is per clone. It indicates the order in which changesets were added to the repository, but has no other significance. The global revision id identifies the changeset across clones. Different developers will have different local revision numbers for the same change, but they will have the same global revision id. Each changeset depends on other changes that came before. However, a changeset does not depend on all previous changes, since some changes were made independently from each other. A changeset records its parent changeset. In fact, in Mercurial a changeset can have up to two parents. When a changeset has two parents, it is the result of a merge. A changeset that is not the parent of other changesets (i.e. it doesn't have any children) is called a head. Mercurial wants to minimize the number of heads in a clone, so it will warn when an operation creates an extra head and will often refuse to perform the operation altogether. Combining heads is called a merge. As far as Mercurial is concerned, each changeset you add (i.e. each commit) depends on the last changeset. However, this is of course not always really true since often different changes are orthogonal to each other. It is possible to tell Mercurial to change the parent of a changeset to some other changeset. This is called rebasing the changeset. Configuration Before you do anything else, it is a good idea to take care of some necessary configuration. Mercurial reads a number of configuration files. Configuration settings in later ones in the list below override settings in earlier ones. • System configuration file, typically in /etc/mercurial. • User-specific configuration file, typically in $HOME/.hgrc (on Windows also %USERPROFILE%\.hgrc, %USERPROFILE%\Mercurial.ini, and %HOME%\Mercurial.ini). • Repository-specific configuration file in .hg/hgrc within the clone. The configuration files all share the same syntax, the Windows INI file syntax, consisting of sections headed by a header in square brackets, and within each section key=value pairs. See the manual hgrc(5) and hg help config for more information. If you're using Mercurial only for MonetDB, you can add all the configurations that are mentioned below to the file $HOME/.hgrc. Otherwise you need to decide which configuration settings can be used for all your Mercurial clones and which should be specific to a clone. If you choose to use clone-specific configuration settings, you do need to make sure that the settings are added to each clone after they have been created. Important Configuration Your Name The minimal configuration consists of telling Mercurial who you are. This is typically done in the user-specific configuration file. Add the following (with appropriate changes) to your configuration file: [ui] username = My Name <[email protected]> Note that the name is actually used by the system in the From address in mails that are sent to the checkin mailing list to notify people of changes and thus the address is public. Line Endings On Windows, text files use the CRLF (Carriage Return - Line Feed) combination as end-of-line indicators, whereas Unix/Linux (including MacOS) uses only LF (Line Feed). On both sets of systems, many programs can deal with either convention, but some programs get confused, and if a file with one type of line ending is edited on a system using the other type, it may well be that all line endings are converted. This would cause a massive change to the file, affecting all lines. This would be very bad. For this reason, it is important that Mercurial converts line endings for you, if needed. However, binary files, such as images, must not be converted. Mercurial uses the eol extension and a file, .hgeol, in the root directory of the working set. This files contains file name patterns with declarations of the type of file (BIN, CRLF, LF, or native). The MonetDB repository already contains this file. In order to enable the line ending conversion, the following configuration needs to be added in your configuration file (this can usually be added to the user-specific file). This should be done on any system, not just on Windows. [extensions] eol = File Name Restrictions If you are on a Linux system, you are urged to fix your configuration so that file names that are not compatible with Windows won't be added. Add the following to your configuration file: [ui] portablefilenames = abort White Space Checks You are strongly urged to add the following configuration to your .hg/hgrc file in all of your MonetDB clones (or to your $HOME/.hgrc file if you don't use Mercurial for other projects). First get a copy of a non-standard extension: hg clone https://dev.monetdb.org/hg/check_whitespace/ This will create a directory check_whitespace in whatever directory you execute this in (preferably not within a clone of an existing repository). Then add the following to your configuration file: [hooks] pretxncommit.whitespace = python:<path-to-check_whitespace-directory>/check_whitespace.py:hook This is a pre transaction hook which will check whether any of the added or changed lines contains incorrect white space. Incorrect white space is currently only defined for Python source code. In Python source code, it is not allowed to have trailing white space or to have TAB characters. The hook will also check for and refuse left over conflict resolution markers and non-empty files not ending with a newline. Optional Configuration Some other configuration ideas are (use hg help extensions for more information about extensions): [extensions] # temporarily save changes shelve = There used to be an extension called autopager which would only use the pager if the output was more than a screen full. This same effect can be had by using the correct options to the program less. To do so, add a pager section: [pager] pager = less -FXR Merge Conflicts Vim users might want to use the following to resolve conflicts: [merge-tools] vimdiff.args = -X $other $local $base vimdiff.priority = 1 vimdiff.premerge = keep Using this, for each file that has a conflict, vimdiff will be started with three open files. From left to right the files are: the other file (the version that is being merged in), the local file (the one that you should be editing), and the base file (the common ancestor of your version and the incoming version). Because of the premerge setting, Mercurial will attempt to merge and start vimdiff in case there are conflicts. In the middle pane you will see the conflict markers which you must resolve. (X)Emacs users might, instead, want to use this (Replace emacs with xemacs if you're into XEmacs): [merge-tools] emacs.args = --eval "(ediff-merge-files-with-ancestor \""$local"\" \""$other"\" \""$base"\" nil \""$output"\")" emacs.priority = 1 Quoting in this and the following examples is important to get right.
Load more

Recommended publications
  • Version Control 101 Exported from Please Visit the Link for the Latest Version and the Best Typesetting
    Version Control 101 Exported from http://cepsltb4.curent.utk.edu/wiki/efficiency/vcs, please visit the link for the latest version and the best typesetting. Version Control 101 is created in the hope to minimize the regret from lost files or untracked changes. There are two things I regret. I should have learned Python instead of MATLAB, and I should have learned version control earlier. Version control is like a time machine. It allows you to go back in time and find out history files. You might have heard of GitHub and Git and probably how steep the learning curve is. Version control is not just Git. Dropbox can do version control as well, for a limited time. This tutorial will get you started with some version control concepts from Dropbox to Git for your needs. More importantly, some general rules are suggested to minimize the chance of file losses. Contents Version Control 101 .............................................................................................................................. 1 General Rules ................................................................................................................................... 2 Version Control for Files ................................................................................................................... 2 DropBox or Google Drive ............................................................................................................. 2 Version Control on Confluence ...................................................................................................
    [Show full text]
  • Generating Commit Messages from Git Diffs
    Generating Commit Messages from Git Diffs Sven van Hal Mathieu Post Kasper Wendel Delft University of Technology Delft University of Technology Delft University of Technology [email protected] [email protected] [email protected] ABSTRACT be exploited by machine learning. The hypothesis is that methods Commit messages aid developers in their understanding of a con- based on machine learning, given enough training data, are able tinuously evolving codebase. However, developers not always doc- to extract more contextual information and latent factors about ument code changes properly. Automatically generating commit the why of a change. Furthermore, Allamanis et al. [1] state that messages would relieve this burden on developers. source code is “a form of human communication [and] has similar Recently, a number of different works have demonstrated the statistical properties to natural language corpora”. Following the feasibility of using methods from neural machine translation to success of (deep) machine learning in the field of natural language generate commit messages. This work aims to reproduce a promi- processing, neural networks seem promising for automated commit nent research paper in this field, as well as attempt to improve upon message generation as well. their results by proposing a novel preprocessing technique. Jiang et al. [12] have demonstrated that generating commit mes- A reproduction of the reference neural machine translation sages with neural networks is feasible. This work aims to reproduce model was able to achieve slightly better results on the same dataset. the results from [12] on the same and a different dataset. Addition- When applying more rigorous preprocessing, however, the per- ally, efforts are made to improve upon these results by applying a formance dropped significantly.
    [Show full text]
  • Introduction to Version Control with Git
    Warwick Research Software Engineering Introduction to Version Control with Git H. Ratcliffe and C.S. Brady Senior Research Software Engineers \The Angry Penguin", used under creative commons licence from Swantje Hess and Jannis Pohlmann. March 12, 2018 Contents 1 About these Notes1 2 Introduction to Version Control2 3 Basic Version Control with Git4 4 Releases and Versioning 11 Glossary 14 1 About these Notes These notes were written by H Ratcliffe and C S Brady, both Senior Research Software Engineers in the Scientific Computing Research Technology Platform at the University of Warwick for a series of Workshops first run in December 2017 at the University of Warwick. This document contains notes for a half-day session on version control, an essential part of the life of a software developer. This work, except where otherwise noted, is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International Li- cense. To view a copy of this license, visit http://creativecommons.org/ licenses/by-nc-nd/4.0/. The notes may redistributed freely with attribution, but may not be used for commercial purposes nor altered or modified. The Angry Penguin and other reproduced material, is clearly marked in the text and is not included in this declaration. The notes were typeset in LATEXby H Ratcliffe. Errors can be reported to [email protected] 1.1 Other Useful Information Throughout these notes, we present snippets of code and pseudocode, in particular snippets of commands for shell, make, or git. These often contain parts which you should substitute with the relevant text you want to use.
    [Show full text]
  • Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management
    Distributed Configuration Management: Mercurial CSCI 5828 Spring 2012 Mark Grebe Configuration Management Configuration Management (CM) systems are used to store code and other artifacts in Software Engineering projects. Since the early 70’s, there has been a progression of CM systems used for Software CM, starting with SCCS, and continuing through RCS, CVS, and Subversion. All of these systems used a single, centralized repository structure. Distributed Configuration Management As opposed to traditional CM systems, Distributed Configuration Management Systems are ones where there does not have to be a central repository. Each developer has a copy of the entire repository and history. A central repository may be optionally used, but it is equal to all of the other developer repositories. Advantages of Distributed Configuration Management Distributed tools are faster than centralized ones since metadata is stored locally. Can use tool to manage changes locally while not connected to the network where server resides. Scales more easily, since all of the load is not on a central server. Allows private work that is controlled, but not released to the larger community. Distributed systems are normally designed to make merges easy, since they are done more often. Mercurial Introduction Mercurial is a cross-platform, distributed configuration management application. In runs on most modern OS platforms, including Windows, Linux, Solaris, FreeBSD, and Mac OSX. Mercurial is written 95% in Python, with the remainder written in C for speed. Mercurial is available as a command line tool on all of the platforms, and with GUI support programs on many of the platforms. Mercurial is customizable with extensions, hooks, and output templates.
    [Show full text]
  • Version Control – Agile Workflow with Git/Github
    Version Control – Agile Workflow with Git/GitHub 19/20 November 2019 | Guido Trensch (JSC, SimLab Neuroscience) Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 2 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich, JSC:SimLab Neuroscience 3 Motivation • Version control is one aspect of configuration management (CM). The main CM processes are concerned with: • System building • Preparing software for releases and keeping track of system versions. • Change management • Keeping track of requests for changes, working out the costs and impact. • Release management • Preparing software for releases and keeping track of system versions. • Version control • Keep track of different versions of software components and allow independent development. [Ian Sommerville,“Software Engineering”] Forschungszentrum Jülich, JSC:SimLab Neuroscience 4 Motivation • Keep track of different versions of software components • Identify, store, organize and control revisions and access to it • Essential for the organization of multi-developer projects is independent development • Ensure that changes made by different developers do not interfere with each other • Provide strategies to solve conflicts CONFLICT Alice Bob Forschungszentrum Jülich, JSC:SimLab Neuroscience 5 Content Motivation Version Control Systems (VCS) Understanding Git GitHub (Agile Workflow) References Forschungszentrum Jülich,
    [Show full text]
  • Colors in Bitbucket Pull Request
    Colors In Bitbucket Pull Request Ligulate Bay blueprints his hays craving gloomily. Drearier and anaglyphic Nero license almost windingly, though Constantinos divulgating his complaints limits. Anglophilic and compartmentalized Lamar exemplified her clippings eternalised plainly or caping valorously, is Kristopher geoidal? Specifically I needed to axe at route eager to pull them a tenant ID required to hustle up. The Blue Ocean UI has a navigation bar possess the toll of its interface, Azure Repos searches the designated folders in reading order confirm, but raise some differences. Additionally for GitHub pull requests this tooltip will show assignees labels reviewers and build status. While false disables it a pull. Be objective to smell a stride, and other cases can have? Configuring project version control settings. When pulling or. This pull list is being automatically deployed with Vercel. Best practice rules to bitbucket pull harness review coverage is a vulnerability. By bitbucket request in many files in revision list. Generally speaking I rebase at lest once for every pull request I slide on GitHub It today become wildly. Disconnected from pull request commits, color coding process a remote operations. The color tags option requires all tags support. Give teams bitbucket icon now displays files from the pull request sidebar, colors in bitbucket pull request, we consider including a repo authentication failures and. Is their question about Bitbucket Cloud? Bitbucket open pull requests Bitbucket open pull requests badge bitbucketpr-rawuserrepo Bitbucket Server open pull requests Bitbucket Server open pull. Wait awhile the browser to finish rendering before scrolling. Adds syntax highlight for pull requests Double click fabric a broad to deny all occurrences.
    [Show full text]
  • Create a Pull Request in Bitbucket
    Create A Pull Request In Bitbucket Waverley is unprofitably bombastic after longsome Joshuah swings his bentwood bounteously. Despiteous Hartwell fathomsbroaches forcibly. his advancements institutionalized growlingly. Barmiest Heywood scandalize some dulocracy after tacit Peyter From an effect is your own pull remote repo bitbucket create the event handler, the bitbucket opens the destination branch for a request, if i am facing is Let your pet see their branches, commit messages, and pull requests in context with their Jira issues. You listen also should the Commits tab at the top gave a skill request please see which commits are included, which provide helpful for reviewing big pull requests. Keep every team account to scramble with things, like tablet that pull then got approved, when the build finished, and negotiate more. Learn the basics of submitting a on request, merging, and more. Now we made ready just send me pull time from our seven branch. Awesome bitbucket cloud servers are some nifty solutions when pull request a pull. However, that story ids will show in the grasp on all specified stories. Workzone can move the trust request automatically when appropriate or a percentage of reviewers have approved andor on successful build results. To cost up the webhook and other integration parameters, you need two set although some options in Collaborator and in Bitbucket. Go ahead but add a quote into your choosing. If you delete your fork do you make a saw, the receiver can still decline your request ask the repository to pull back is gone. Many teams use Jira as the final source to truth of project management.
    [Show full text]
  • Distributed Revision Control with Mercurial
    Distributed revision control with Mercurial Bryan O’Sullivan Copyright c 2006, 2007 Bryan O’Sullivan. This material may be distributed only subject to the terms and conditions set forth in version 1.0 of the Open Publication License. Please refer to Appendix D for the license text. This book was prepared from rev 028543f67bea, dated 2008-08-20 15:27 -0700, using rev a58a611c320f of Mercurial. Contents Contents i Preface 2 0.1 This book is a work in progress ...................................... 2 0.2 About the examples in this book ..................................... 2 0.3 Colophon—this book is Free ....................................... 2 1 Introduction 3 1.1 About revision control .......................................... 3 1.1.1 Why use revision control? .................................... 3 1.1.2 The many names of revision control ............................... 4 1.2 A short history of revision control .................................... 4 1.3 Trends in revision control ......................................... 5 1.4 A few of the advantages of distributed revision control ......................... 5 1.4.1 Advantages for open source projects ............................... 6 1.4.2 Advantages for commercial projects ............................... 6 1.5 Why choose Mercurial? .......................................... 7 1.6 Mercurial compared with other tools ................................... 7 1.6.1 Subversion ............................................ 7 1.6.2 Git ................................................ 8 1.6.3
    [Show full text]
  • DVCS Or a New Way to Use Version Control Systems for Freebsd
    Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions DVCS or a new way to use Version Control Systems for FreeBSD Ollivier ROBERT <[email protected]> BSDCan 2006 Ottawa, Canada May, 12-13th, 2006 Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions Agenda 1 Brief history of VCS 2 FreeBSD context & gures 3 Is Arch/baz suited for FreeBSD? 4 Mercurial to the rescue 5 New processes & policies needed 6 Conclusions Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions The ancestors: SCCS, RCS File-oriented Use a subdirectory to store deltas and metadata Use lock-based architecture Support shared developments through NFS (fragile) SCCS is proprietary (System V), RCS is Open Source a SCCS clone exists: CSSC You can have a central repository with symlinks (RCS) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS, the de facto VCS for the free world Initially written as shell wrappers over RCS then rewritten in C Centralised server Easy UI Use sandboxes to avoid locking Simple 3-way merges Can be replicated through CVSup or even rsync Extensive documentation (papers, websites, books) Free software and used everywhere (SourceForge for example) Ollivier ROBERT <[email protected]> DVCS or a new way to use Version Control Systems for FreeBSD Brief history of VCS FreeBSD context & gures Is Arch/baz suited for FreeBSD? Mercurial to the rescue New processes & policies needed Conclusions CVS annoyances and aws BUT..
    [Show full text]
  • INF5750/9750 - Lecture 1 (Part III) Problem Area
    Revision control INF5750/9750 - Lecture 1 (Part III) Problem area ● Software projects with multiple developers need to coordinate and synchronize the source code Approaches to version control ● Work on same computer and take turns coding ○ Nah... ● Send files by e-mail or put them online ○ Lots of manual work ● Put files on a shared disk ○ Files get overwritten or deleted and work is lost, lots of direct coordination ● In short: Error prone and inefficient The preferred solution ● Use a revision control system. RCS - software that allows for multiple developers to work on the same codebase in a coordinated fashion ● History of Revision Control Systems: ○ File versioning tools, e.g. SCCS, RCS ○ Central Style - tree versioning tools. e.g. CVS ○ Central Style 2 - tree versioning tools e.g. SVN ○ Distributed style - tree versioning tools e.g. Bazaar ● Modern DVCS include Git, Mercurial, Bazaar Which system in this course? ● In this course we will be using GIT as the version control system ● We will use the UIO git system, but you can also make git accounts on github.com or bitbucket for your own projects ● DHIS2 uses a different system: Launchpad/Bazaar How it works Working tree: Local copy of the source code Repository: residing on the Central storage of developer’s the source code at computer (a client) a server synchronize synchronize Commit Commit locally Centralized De-centralized The repository Central ● Remembers every change ever written to it (called commits) ● You can have a central or local repository. ○ Central = big server in
    [Show full text]
  • Version Control Key Points ======
    Version Control Key Points ========================== Mike Jackson, The Software Sustainability Institute. This work is licensed under the Creative Commons Attribution License. Copyright (c) Software Carpentry and The University of Edinburgh 2012. See http://software-carpentry.org/license.html for more information. Derived from Chris Cannam's original at, https://code.soundsoftware.ac.uk/projects/easyhg/wiki/SC2012BootcampPl an. .. Written in reStructuredText, http://docutils.sourceforge.net/rst.html. Prerequisites ------------- Mercurial, BitBucket. Introduction ------------ Cover VersionControl.ppt, slides 1-2. Use Mercurial command-line. EasyMercurial GUI as a visually appealing alternative - once the concepts are understood. Create a repository directory and add a file -------------------------------------------- hg and Mercury. Set an editor for providing commit messages e.g. nano. :: export EDITOR=nano Or xemacs :: export EDITOR=xemacs Or vi. :: export EDITOR=vi Create repository. :: hg init hg status file.txt "?" means repository does not know about it. :: hg add file.txt hg status file.txt "A" means repository has scheduled it for addition but not yet added it. :: hg commit file.txt abort: no username supplied message /home/user/.hgrc file contains common settings. :: [ui] username = Boot Camp <[email protected]> :: hg commit file.txt Commit message records "why" changes were made. "made a change" messages are redundant. "Commit 1, 2..." messages are redundant. Messages must have meaning to others who may read them (or the original author 6 months from now). :: hg status file.txt No information means repository knows about it and it's up-to-date. .hgignore can record files to ignore e.g. ~ files, .o files, .class files etc. :: syntax: glob *~ Add to repository.
    [Show full text]
  • Darcs 2.0.0 (2.0.0 (+ 75 Patches)) Darcs
    Darcs 2.0.0 (2.0.0 (+ 75 patches)) Darcs David Roundy April 23, 2008 2 Contents 1 Introduction 7 1.1 Features . 9 1.2 Switching from CVS . 11 1.3 Switching from arch . 12 2 Building darcs 15 2.1 Prerequisites . 15 2.2 Building on Mac OS X . 16 2.3 Building on Microsoft Windows . 16 2.4 Building from tarball . 16 2.5 Building darcs from the repository . 17 2.6 Building darcs with git . 18 2.7 Submitting patches to darcs . 18 3 Getting started 19 3.1 Creating your repository . 19 3.2 Making changes . 20 3.3 Making your repository visible to others . 20 3.4 Getting changes made to another repository . 21 3.5 Moving patches from one repository to another . 21 3.5.1 All pulls . 21 3.5.2 Send and apply manually . 21 3.5.3 Push . 22 3.5.4 Push —apply-as . 22 3.5.5 Sending signed patches by email . 23 3.6 Reducing disk space usage . 26 3.6.1 Linking between repositories . 26 3.6.2 Alternate formats for the pristine tree . 26 4 Configuring darcs 29 4.1 prefs . 29 4.2 Environment variables . 32 4.3 General-purpose variables . 33 4.4 Remote repositories . 34 3 4 CONTENTS 4.5 Highlighted output . 36 4.6 Character escaping and non-ASCII character encodings . 36 5 Best practices 39 5.1 Introduction . 39 5.2 Creating patches . 39 5.2.1 Changes . 40 5.2.2 Keeping or discarding changes . 40 5.2.3 Unrecording changes .
    [Show full text]