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?
;
