CSC323 2010S Software Design

Beautiful Code 2: Subversion's Delta Editor

Fogel, Karl (2007). Subversion's Delta Editor: Interface as Ontology. Chapter 2 (pp. 11-28) in Oram & Wilson (eds), Beautiful Code. Sebastapol, CA: O'Reilly.

I'm a little confused with what exactly the batons are doing. Are they carrying the data to be stored in the pools, or are they simply a signifier that the data stores are able to be written to?

I don't understand the mechanics of the "merge" operation; when changes are made by two or more users, subversion will determine if these changes do not overwrite one another and if not will merge them into a single new revision. This seems like it could have dangerous consequences, since Subversion cannot accurately predict which changes are contradictory. Since this decision is already left up to the users if the changes do affect the same material, why aren't all colliding changes left up to a person to resolve?

Is it really beneficial to keep every revision? How often do you actually want to go back 50 revisions on a project? Considering how difficult it is to make perfect code (even in small segments), large projects could potentially have several thousands of revisions (eg. this chapter was based on revision 21731 of the delta editor) which seem like they would mostly just take up space.

What sort of real-world performance benefits does Subversion's method of storing deltas give? What % compression is achieved? How does the overhead change this efficiency for small projects?

It sounds like the main conceptual difference between SVN and Git is centralization vs. decentralization. In SVN, everyone gets centrally stored and controlled code, while colleagues using Git without a central repository must push and pull from each other. Does this difference have any significant impact on workflow? Is one better?

It seems that the actual implementation code was missing- all that was listed was the struct (API list of commands) and an example of how to use the delta editor. How does the actual tree conversion actually work? Where is the code? Or is the point of this chapter the beauty of the collection of methods (the API), and not each method's specific implementation? Does this really meet the the criterion of beautiful code if we can't seem the implementation?

What does the subtitle "Interface as Ontology" mean? I looked up ontology but that didn't help.

Will you do a diagram on the board of how the tree works? I'm not entirely sure I understand it.

How are pools functioning in this code? Specifically, how are pools related to batons? Are batons assigned to a pool when the baton is created?

I don't fully understand the term call back function. Is the delta editor a set of call-back functions? When do these functions get called, by the user, or by SVN?

I'm a little confused with what exactly the batons are doing. Are they carrying the data to be stored in the pools, or are they simply a signifier that the data stores are able to be written to?

Disclaimer: I usually create these pages on the fly, which means that I rarely proofread them and they may contain bad grammar and incorrect details. It also means that I tend to update them regularly (see the history for more details). Feel free to contact me with any suggestions for changes.

This document was generated by Siteweaver on Tue Mar 2 09:41:10 2010.
The source to the document was last modified on Tue Mar 2 09:41:07 2010.
This document may be found at

You may wish to validate this document's HTML ; Valid CSS! ; Creative Commons License

Samuel A. Rebelsky,

Copyright © 2010 Samuel A. Rebelsky. This work is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. To view a copy of this license, visit or send a letter to Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 94105, USA.