Version Control with Subversion - Login

Embedding SubversionSubversion's working copy library, libsvn_wc, is directly responsible for managing thedata in the working copies. To accomplish this, the library stores administrative informationabout each working copy directory within a special subdirectory. This subdirectory, named.svn, is present in each working copy directory and contains various other files and directoriesthat record state and provide a private workspace for administrative action. For thosefamiliar with CVS, this .svn subdirectory is similar in purpose to the CVS administrative directoriesfound in CVS working copies. For more information about the .svn administrativearea, see the section called “Inside the Working Copy Administration Area” later in thischapter.The Subversion client library, libsvn_client, has the broadest responsibility; its job is tomingle the functionality of the working copy library with that of the Repository Access layer,and then to provide the highest-level API to any application that wishes to perform generalrevision control actions. For example, the function svn_client_checkout() takes aURL as an argument. It passes this URL to the RA layer and opens an authenticated sessionwith a particular repository. It then asks the repository for a certain tree, and sendsthis tree into the working copy library, which then writes a full working copy to disk (.svndirectories and all).The client library is designed to be used by any application. While the Subversion sourcecode includes a standard command-line client, it should be very easy to write any numberof GUI clients on top of the client library. New GUIs (or any new client, really) for Subversionneed not be clunky wrappers around the included command-line client—they have fullaccess via the libsvn_client API to the same functionality, data, and callback mechanismsthat the command-line client uses. In fact, the Subversion source code tree contains asmall C program (which you can find at tools/examples/minimal_client.c) that exemplifieshow to wield the Subversion API to create a simple client program.Binding Directly—A Word About CorrectnessWhy should your GUI program bind directly with a libsvn_client instead of actingas a wrapper around a command-line program? Besides simply being more efficient,it can be more correct as well. A command-line program (such as the one suppliedwith Subversion) that binds to the client library needs to effectively translate feedbackand requested data bits from C types to some form of human-readable output. Thistype of translation can be lossy. That is, the program may not display all of the informationharvested from the API or may combine bits of information for compact representation.If you wrap such a command-line program with yet another program, the second programhas access only to already interpreted (and as we mentioned, likely incomplete)information, which it must again translate into its representation format. With eachlayer of wrapping, the integrity of the original data is potentially tainted more andmore, much like the result of making a copy of a copy (of a copy…) of a favorite audioor video cassette.But the most compelling argument for binding directly to the APIs instead of wrappingother programs is that the Subversion project makes compatibility promises regardingits APIs. Across minor versions of those APIs (such as between 1.3 and 1.4), nofunction's prototype will change. In other words, you aren't forced to update your program'ssource code simply because you've upgraded to a new version of Subversion.Certain functions might be deprecated, but they still work, and this gives you a bufferof time to eventually embrace the newer APIs. These kinds of compatibility promisesdo not exist for Subversion command-line program output, which is subject to changefrom release to release.Inside the Working Copy Administration Area212