• Choose a category
• All
• Classic-Fiction

It was only after we began throwing the new delta editor at various problems that these features began to show their value. For example, one thing we wanted to implement was change summarization: a way to show an overview of the difference between two trees without giving the details. This is useful when someone wants to know which files in her working copy have changed in the repository since she checked them out, but doesn't need to know exactly what the changes were.

Here's a slightly simplified version of how it works: the client tells the server what revision tree the working copy is based on, and then the server tells the client the difference between that revision tree and the latest one, using the delta editor. The server is the producer, the client is the consumer.

Using the repository from earlier in the chapter, in which we built up a change to /A/fish/tuna to create revision 2, let's see how this would look as a series of editor calls, sent by the server to a client whose tree is still at revision 1. The if block about two-thirds of the way through is where we decide whether this is a summarization edit or a "give me everything" edit:

Code View: Scroll / Show All

svn_delta_editor_t *editor

void *edit_baton;

/* In real life, this would be a passed-in parameter, of course. */

int summarize_only = TRUE;

/* In real life, these variables would be declared in subroutines,

so that their lifetimes would be bound to the stack frame just

as the objects they point to are bound by the tree edit frame. */

void *root_baton;

void *dir_baton;

void *subdir_baton;

void *file_baton;

/* Similarly, there would be subpools, not just one top-level pool. */

apr_pool_t *pool = svn_pool_create();

/* Each use of the delta editor interface starts by requesting the

particular editor that implements whatever you need, e.g.,

streaming the edit across the network, applying it to a working

copy, etc. */

Get_Update_Editor(&editor, &eb,

some_repository,

1, /* source revision number */

2, /* target revision number */

pool);

/* Now we drive the editor. In real life, this sequence of calls

would be dynamically generated, by code that walks the two

repository trees and invokes editor->foo() as appropriate. */

editor->open_root(edit_baton, pool, &root_baton);

editor->open_directory("A", root_baton, pool, &dir_baton);

editor->open_directory("A/fish", dir_baton,pool, &subdir_baton);

editor->open_file("A/fish/tuna", subdir_baton, pool, &file_baton);

if (! summarize_only)

{

svn_txdelta_window_handler_t window_handler;

void *window_handler_baton;

svn_txdelta_window_t *window;

editor->apply_textdelta(file_baton, pool

apr_pool_t *pool,

&window_handler,

&window_handler_baton);

do {

window = Get_Next_TextDelta_Window(...);

window_handler(window, window_handler_baton);

} while (window);

}

editor->close_file(file_baton, pool);

editor->close_directory(subdir_baton, pool);

editor->close_directory(dir_baton, pool);

editor->close_directory(root_baton, pool);

editor->close_edit(edit_baton, pool);

As this example shows, the distinction between a summary of a change and the full version of the change falls naturally along the boundaries of the delta editor interface, allowing us to use the same code path for both purposes. While it happens that the two revision trees in this example were adjacent (revision 1 and revision 2), they didn't have to be. The same method would work for any two trees, even with many revisions between them, as is the case when a working copy hasn't been updated for a long time. And it would work when the two trees are in reverse order—that is, with the newer revision first. This is useful for reverting a change.

Subversion's Delta Editor: Interface As Ontology > Abstraction As a Spectator Sport

2.5. Abstraction As a Spectator Sport

Our next indication of the delta editor's flexibility came when we