This file describes the repository's internal organizational scheme. This directory contains hook script templates and hook scripts, if any have been installed. Subversion uses this directory to house repository lock files, used for managing concurrent access to the repository. This is a brief text file containing merely a notice to readers that the directory they are looking in is a Subversion repository.
Prior to Subversion 1. Subversion 1. Of course, when accessed via the Subversion libraries, this otherwise unremarkable collection of files and directories suddenly becomes an implementation of a virtual, versioned filesystem, complete with customizable event triggers. The cost of branching and tagging need not be proportional to the project size.
Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time. Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs.
This makes Subversion extremely maintainable and usable by other applications and languages. On one end is a Subversion repository that holds all of your versioned data. Between these extremes are multiple routes through various Repository Access RA layers.
Some of these routes go across computer networks and through network servers which then access the repository. Others bypass the network altogether and access the repository directly. Subversion, once installed, has a number of different pieces.
The following is a quick overview of what you get. Don't be alarmed if the brief descriptions leave you scratching your head—there are plenty more pages in this book devoted to alleviating that confusion. A program for reporting the state in terms of revisions of the items present of a working copy. A custom standalone server program, runnable as a daemon process or invokable by SSH; another way to make your repository available to others over a network. Assuming you have Subversion installed correctly, you should be ready to start.
The next two chapters will walk you through the use of svn , Subversion's command-line client program. What is Subversion? Prev Preface Next. Basic Version-Control Concepts. The Repository. Figure 2. Prev Next Moving On Home Versioning Models. The entire tree-delta is complete.
Of course, at any point above, the repository may reject an edit. If this is the case, the client aborts the transmission and the repository hasn't changed a bit. Thank goodness for transactions! Note, however, that this "editor interface" works in the other direction as well. When the repository wishes to update a client's working copy, it is the client's reponsibility to give a custom editor-object to the server, and the server is the editor-driver.
Tree-deltas move across the network, in both directions, using the same interface. Custom editor-implementations can be written to do anything one might want; the editor-driver has no idea what is happening on the other side of the interface. For example, an editor might.
Whatever the case, it's easy to "swap" editors around, and make client and server do new and interesting things. The Subversion client is built on three libraries. One operates strictly on the working copy and does not talk to the repository. Another talks to the repository but never changes the working copy. The third library uses the first two to provide operations such as commit and update — operations which need to both talk to the repository and change the working copy. The initial client is a Unix-style command-line tool like standard CVS , but it should be easy to write a GUI client as well, based on the same libraries.
The libraries capture the core Subversion functionality, segregating it from user interface concerns. Working copies are client-side directory trees containing both versioned data and Subversion administrative files.
The functions in the working copy management library are the only functions in Subversion which operate on these trees. This section gives an overview of how working copies are arranged physically, but is not a full specification of working copy layout. As with CVS, Subversion working copies are simply directory trees with special administrative subdirectories, in this case named ". Although it would often be possible to deduce certain information such as the original repository by examining parent directories, this is avoided in favor of making each directory be as much a self-contained unit as possible.
For example, immediately after a checkout the administrative information for the entire working tree could be stored in one top-level file. But subdirectories instead keep track of their own revision information. This would be necessary anyway once the user starts committing new revisions for particular files, and it also makes it easier for the user to prune a big, complete tree into a small subtree and still have a valid working copy.
A format file, which indicates which version of the working copy adm format this is so future clients can be backwards compatible easily. A text-base directory, containing the pristine repository revisions of the files in the corresponding working directory.
An entries file, which holds revision numbers and other information for this directory and its files, and records the presence of subdirs. It also contains the repository URLs that each file and directory came from. A props directory, containing property names and values for each file in the working directory. A prop-base directory, containing pristine property names and values for each file in the working directory.
A dir-props file, recording properties for this directory. A dir-prop-base file, recording pristine properties for this directory. A lock file, whose presence implies that some client is currently operating on the administrative area.
A tmp directory, for holding scratch-work and helping make working copy operations more crash-proof. A log file. If present, indicates a list of actions that need to be taken to complete a working-copy-operation that is still "in progress". These functions correspond to user-level client commands. In theory, any client interface command-line, GUI, emacs, Python, etc. Therefore, there is not just one Subversion protocol - in fact, at present, there are two:.
For a detailed description of exactly how Greg Stein gstein lyra. In Subversion, however, the server is just a set of libraries that implements repositories and makes them available to other programs. No networking is required. There are two main libraries: the Subversion Filesystem library, and the Subversion Repository library. This library implements a hierarchical filesystem which supports atomic changes to directory trees, and records a complete history of the changes. In addition to recording changes to file and directory contents, the Subversion Filesystem records changes to file meta-data see discussion of properties in Model — The versioning model used by Subversion.
First, read the section below Repository Structure for a general overview of how the filesystem works. Some details in that document are specific to the BDB-based filesystem implementation. To begin, please be sure that you're already casually familiar with Subversion's ideas of files, directories, and revision histories.
If not, see Model — The versioning model used by Subversion. We can now offer precise, technical descriptions of the terms introduced there. Every revision has a root directory.
Every revision's node number is a valid node number, and the node it refers to is always a directory. We call this the revision's root directory. Revision 0 always contains an empty root directory. This baseline makes it easy to check out whole projects from the repository. Directories contain only valid links. Every directory entry's node is a valid node number.
Directory entries can be identified by name. For any directory d , every directory entry in d has a distinct name. Directories can have more than one parent. The Unix file system does not allow more than one hard link to a directory, but Subversion does allow the analogous situation.
Thus, the directories in a Subversion repository form a directed acyclic graph DAG , not a tree. There are no dead nodes. Every node is a child of some revision's root directory. This section provides a conversational explanation of how the repository actually stores and revisions file trees.
Only the file tuna is a regular file, everything else in myproj is a directory. Let's see what this looks like as an abstract data structure in the repository, and how that structure works in various operations such as update, commit, and branch. In the diagrams that follow, lines represent parent-to-child connections in a directory hierarchy.
Boxes are "nodes". A node is either a file or a directory — a letter in the upper left indicates which kind. Parent-child links go both ways i. At the top of the repository is an array of revision numbers, stretching off to infinity. Since the project is at revision 1, only index 1 points to anything; it points to the root node of revision 1 of the project:.
What happens when we modify tuna and commit? First, we make a new tuna node, containing the latest text. The new node is not connected to anything yet, it's just hanging out there in space:. Now it gets more tricky: we need to create a new revision of the root directory. Therefore, our new root directory also has an entry that still points to the old directory B node!
In this case, the new tree becomes revision 2 in the repository. There are many trees in the repository, and many of them share nodes. Easy reads. If a filesystem reader wants to locate revision X of file foo. Writers don't interfere with readers. Writers can continue to create new nodes, bubbling their way up to the top, and concurrent readers cannot see the work in progress.
File structure is versioned. Unlike CVS, the very structure of each tree is being saved from revision to revision. File and directory renames, additions, and deletions are part of the repository's history. Let's demonstrate the last point by renaming the tuna to book.
From here, we finish with the bubble-up process. In a nutshell, they're one and the same thing. Because nodes are so easily shared, we simply create a new directory entry that points to an existing directory node.
Now we're all set. In the future, the contents of directories A and B may change quite a lot. However, assuming we never make any changes to directory T, it will always point to a particular pristine revision of directory A at some point in time. Thus, T is a tag. In theory, we can use some kind of authorization system to prevent anyone from writing to directory T.
However, if we do decide to allow commits in directory T, and now our repository tree increments to revision 8, then T becomes a branch. Every commit to the repository creates an entire line of new directory nodes! Like many other revision control systems, Subversion stores changes as differences. It doesn't make complete copies of nodes; instead, it stores the latest revision as a full text, and previous revisions as a succession of reverse diffs the word "diff" is used loosely here — for files, it means vdeltas, for directories, it means a format that expresses changes to directories.
The filesystem's data will probably be stored in a collection of. In the future, of course, contributors are free modify the Subversion filesystem to operate with more powerful SQL database. A Subversion repository is a directory that contains a number of components:. The Subversion filesystem is just that: a filesystem.
But it's also useful to provide an API that acts at the level of the repository. A pre-commit-hook script might check for a valid log message, and a post-commit-hook script might send an email to a mailing list. Additionally, the repository library provides convenience routines for examining and manipulating the filesystem.
For example, a routine to generate a tree-delta by comparing two revisions, routines for constructing new transactions, routines for querying log messages, and routines for exporting and importing filesystem data. If newer versions of this license are posted there, you may use a newer version instead, at your option. Goals — The goals of the Subversion project The goal of the Subversion project is to write a version control system that takes over CVS's current and future user base If you're not familiar with CVS or its shortcomings, then skip to Model — The versioning model used by Subversion.
So what does Subversion have that CVS doesn't? Tagging and branching are constant-time and constant-space. It has internationalization support. Text vs binary issues Historically, binary files have been problematic in CVS for two unrelated reasons: keyword expansion, and line-end conversion. Miscellaneous new behaviors Log messages Subversion has a flexible log message policy a small matter, but one dear to our hearts.
Client side diff plug-ins Subversion supports client-side plug-in diff programs. Note: This feature does not exist yet, but is planned for post Better merging Subversion remembers what has already been merged in and what hasn't, thereby avoiding the problem, familiar to CVS users, of spurious conflicts on repeated merges. For details, see Merging and Ancestry. Conflicts resolution For text files, Subversion resolves conflicts similarly to CVS, by folding repository changes into the working files with conflict markers.
Thus, for any conflict, the user has four files readily at hand: the original working copy file with local mods the older repository file the newest repository file the merged file, with conflict markers and in a binary file conflict, the user has all but the last. Working Directories and Repositories Suppose you are using Subversion to manage a software project.
We explain below what happens when both you and Felix make changes to the same file.
0コメント