Even though the examples in this chapter show people sharing collections of program source code, keep in mind that Subversion can manage any sort of file collection\u2014it’s not limited to helping computer programmers.<\/p>\n
Version Control Basics<\/h3>\n
A version control system (or revision control system) is a system that tracks incremental versions (or revisions) of files and, in some cases, directories over time. Of course, merely tracking the various versions of a user’s (or group of users’) files and directories isn’t very interesting in itself. What makes a version control system useful is the fact that it allows you to explore the changes which resulted in each of those versions and facilitates the arbitrary recall of the same.<\/p>\n
In this section, we’ll introduce some fairly high-level version control system components and concepts. We’ll limit our discussion to modern version control systems\u2014in today’s interconnected world, there is very little point in acknowledging version control systems which cannot operate across wide-area networks.<\/p>\n
The Repository<\/h4>\n
At the core of the version control system is a repository<\/a>, which is the central store of that system’s data. The repository usually stores information in the form of a\u00a0filesystem tree<\/i><\/a>\u2014a hierarchy of files and directories. Any number of\u00a0clients<\/i> connect to the repository, and then read or write to these files. By writing data, a client makes the information available to others; by reading data, the client receives information from others. Figure 1.1, \u201cA typical client\/server<\/a> system\u201d illustrates this.<\/span><\/p>\n Figure 1.1. A typical client\/server system \u00a0<\/b><\/p>\n Why is this interesting? So far, this sounds like the definition of a typical file server. And indeed, the repository\u00a0is<\/i>\u00a0a kind of file server, but it’s not your usual breed. What makes the repository special is that as the files in the repository are changed, the repository remembers each version of those files.<\/p>\n When a client reads data from the repository, it normally sees only the latest version of the filesystem tree. But what makes a version control client interesting is that it also has the ability to request previous states of the filesystem from the repository. A version control client can ask historical questions such as \u201cWhat did this directory contain last Wednesday?\u201d and \u201cWho was the last person to change this file, and what changes did he make?\u201d These are the sorts of questions that are at the heart of any version control system.<\/p>\n A version control system’s value comes from the fact that it tracks versions of files and directories, but the rest of the software universe doesn’t operate on \u201cversions of files and directories\u201d. Most software programs understand how to operate only on a\u00a0single<\/i>\u00a0version of a specific type of file. So how does a version control user interact with an abstract\u2014and, often, remote\u2014repository full of multiple versions of various files in a concrete fashion? How does his or her word processing software, presentation software, source code editor, web design software, or some other program\u2014all of which trade in the currency of simple data files\u2014get access to such files? The answer is found in the version control construct known as a\u00a0working copy<\/i>.<\/p>\n A working copy is, quite literally, a local copy of a particular version of a user’s VCS-managed data upon which that user is free to work. Working copies1 appear to other software just as any other local directory full of files, so those programs don’t have to be \u201cversion-control-aware\u201d in order to read from and write to that data. The task of managing the working copy and communicating changes made to its contents to and from the repository falls squarely to the version control system’s client software.<\/p>\n If the primary mission of a version control system is to track the various versions of digital information over time, a very close secondary mission in any modern version control system is to enable collaborative editing and sharing of that data. But different systems use different strategies to achieve this. It’s important to understand these different strategies, for a couple of reasons. First, it will help you compare and contrast existing version control systems, in case you encounter other systems similar to Subversion. Beyond that, it will also help you make more effective use of Subversion, since Subversion itself supports a couple of different ways of working.<\/p>\n All version control systems have to solve the same fundamental problem: how will the system allow users to share information, but prevent them from accidentally stepping on each other’s feet? It’s all too easy for users to accidentally overwrite each other’s changes in the repository.<\/p>\n Consider the scenario shown in Figure 1.2, \u201cThe problem to avoid\u201d. Suppose we have two coworkers, Harry and Sally. They each decide to edit the same repository file at the same time. If Harry saves his changes to the repository first, it’s possible that (a few moments later) Sally could accidentally overwrite them with her own new version of the file. While Harry’s version of the file won’t be lost forever (because the system remembers every change), any changes Harry made\u00a0won’t<\/i>\u00a0be present in Sally’s newer version of the file, because she never saw Harry’s changes to begin with. Harry’s work is still effectively lost\u2014or at least missing from the latest version of the file\u2014and probably by accident. This is definitely a situation we want to avoid!<\/p>\n","protected":false},"excerpt":{"rendered":"
\n<\/b><\/p>\n![\"\"](\"https:\/\/www.booksofall.com\/de\/wp-content\/uploads\/sites\/9\/2023\/05\/img_645af895e9379.png\")
<\/p>\nThe Working Copy<\/h4>\n
Versioning Models<\/h4>\n
The problem of file sharing<\/h5>\n