Product Description

Written by members of the development team that maintains Subversion, this is the official guide and reference manual for the popular open source revision control technology. The new edition covers Subversion 1.5 with a complete introduction and guided tour of its capabilities, along with best practice recommendations. "Version Control with Subversion" is useful for people from a wide variety of backgrounds, from those with no previous version control experience to experienced system administrators. Subversion is the perfect tool to track individual changes when several people collaborate on documentation or, particularly, software development projects. As a more powerful and flexible successor to the CVS revision control system, Subversion makes life so much simpler, allowing each team member to work separately and then merge source code changes into a single repository that keeps a record of each separate version.Inside the updated edition "Version Control with Subversion", you'll find: an introduction to Subversion and basic concepts behind version control; a guided tour of the capabilities and structure of Subversion 1.5 ; guidelines for installing and configuring Subversion to manage programming, documentation, or any other team-based project; detailed coverage of complex topics such as branching and repository administration; advanced features such as properties, externals, and access control; and, a guide to best practices. It is a complete Subversion reference and troubleshooting guide. If you've never used version control, you'll find everything you need to get started. And if you're a seasoned CVS pro, this book will help you make a painless leap into Subversion.

Product Details

• Amazon Sales Rank: #79419 in Books
• Published on: 2008-10-02
• Original language: English
• Number of items: 1
• Binding: Paperback
• 430 pages

From the Publisher
Version Control with Subversion introduces the powerful new versioning tool designed to be the successor to CVS. An introduction to Subversion is followed by a guided tour of its capabilities. Later chapters cover more complex topics of branching, repository administration, and other advanced features. If you've never used version control, you'll find everything you need to get started. And if you're a seasoned CVS pro, it will help you make a painless leap into Subversion.

About the Author
C. Michael Pilato (Mike) is a core Subversion developer, and a leader in the Subversion community. He is currently employed by CollabNet, where he spends his days improving Subversion and other tools with which it integrates. He lives in North Carolina.

Ben Collins-Sussman has been a sysadmin and programmer for ten years, and is one of the original designers and authors of Subversion. He currently works for CollabNet as a Subversion developer and community leader. He lives in Illinois.

Brian W. Fitzpatrick is a member of the Apache Software Foundation and currently works for Google. He has been involved with Subversion in one way or another since its inception in early 2000. He lives in Illinois.

Excerpted from Version Control with Subversion by Ben Collins-Sussmann, Brian W. Fitzpatrick, C. Michael Pilato. Copyright © 2004. Reprinted by permission. All rights reserved.
CHAPTER 2 - Basic Concepts

This chapter is a short, casual introduction to Subversion. If you’re new to version control, this chapter is definitely for you. We begin with a discussion of general version control concepts, work our way into the specific ideas behind Subversion, and show some simple examples of Subversion in use.

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—it’s not limited to helping computer programmers.

The Repository
Subversion is a centralized system for sharing information. At its core is a repository, which is a central store of data. The repository stores information in the form of a filesystem tree—a typical hierarchy of files and directories. Any number of clients 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. Why is this interesting? So far,this sounds like the definition of a typical file server. And, indeed, the repository is a kind of file server, although it’s not your usual breed. What makes the Subversion repository special is that it remembers every change ever written to it: every change to every file, and even changes to the directory tree itself, such as the addition, deletion, and rearrangement of files and directories.

When a client reads data from the repository, it normally sees only the latest version of the filesystem tree. But the client also has the ability to view previous states of the filesystem. For example, a client can ask historical questions like, What did this directory contain last Wednesday? or Who was the last person to change this file, and what changes did they make? These are the sorts of questions that are at the heart of any version control system: systems that are designed to record and track changes to data over time.

Versioning Models
The core mission of a version control system is to enable collaborative editing and sharing of data. However, different systems use different strategies to achieve this.

The Problem of File Sharing
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.

Consider the scenario shown in Figure 2-2. Suppose we have two co-workers, 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, then 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 won’t be 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—or at least missing from the latest version of the file—and probably by accident. This is definitely a situation we want to avoid!

The Lock-Modify-Unlock Solution
Many version control systems use a lock-modify-unlock model to address this problem. In such a system, the repository allows only one person to change a file at a time. First Harry must lock the file before he can begin making changes to it. Locking a file is a lot like borrowing a book from the library; if Harry has locked a file, then Sally cannot make any changes to it. If she tries to lock the file, the repository will deny the request. All she can do is read the file, and wait for Harry to finish hischanges and release his lock. After Harry unlocks the file, his turn is over, and now Sally can take her turn by locking and editing. Figure 2-3 demonstrates this simple solution.

The problem with the lock-modify-unlock model is that it’s a bit restrictive, and often becomes a roadblock for users:

Locking may cause administrative problems.
Sometimes Harry locks a file and then forget about it. Meanwhile, because Sally is still waiting to edit the file, her hands are tied. And then Harry goes on vacation. Now Sally has to get an administrator to release Harry’s lock. The situation ends up causing a lot of unnecessary delay and wasted time.

Locking may cause unnecessary serialization.
What if Harry is editing the beginning of a text file, and Sally simply wants to edit the end of the same file? These changes don’t overlap at all. They could easily edit the file simultaneously, and no great harm would come, assuming the changes were properly merged together. There’s no need for them to take turns in this situation.

Locking may create a false sense of security.
Pretend that Harry locks and edits file A, while Sally simultaneously locks and edits file B. But suppose that A and B depend on one another, and the changesmade to each are semantically incompatible. Suddenly A and B don’t work together anymore. The locking system was powerless to prevent the problem—yet it somehow provided a false sense of security. It’s easy for Harry and Sally to imagine that by locking files, each is beginning a safe, insulated task, and thus inhibits them from discussing their incompatible changes early on.

The Copy-Modify-Merge Solution
Subversion, CVS, and other version control systems use a copy-modify-merge model as an alternative to locking. In this model, each user’s client contacts the project repository and creates a personal working copy—a local reflection of the repository’s files and directories. Users then work in parallel, modifying their private copies. Finally, the private copies are merged together into a new, final version. The version control system often assists with the merging, but ultimately a human being is responsible for making it happen correctly.

Customer Reviews

Excellent book for users and admins
This is an excellent book on Subversion. It covers all the core operations for end users and has plenty of content for administrators. Like Subversion the tool, the book is elegant and simple. I don't think I need to add any more except that if you're thinking about using Subversion then don't hesitate to try it: its a great tool, a very worthy replacement for CVS (and some of terrible source control systems you have to pay good money for). This book will help you get up to speed very quickly - its especially useful for those migrating from CVS.

Good book
I have this and the Pragmatic one. I think the Pragmatic one is the better book, it's much more readable but then I think this one becomes more of a reference book.

So, if you can't make your mind up, go for the Pragmatic one. For the best of both worlds, get both!

More detail than the Pragmatic book
I read "Pragmatic Version Control: Using Subversion" before reading "Version Control with Subversion". For most people, I would say that is the correct order in which to approach these two books. The Pragmatic book is much more readable, but "Version Control with Subversion" goes into greater depth, answering some of the questions that the Pragmatic book doesn't. It still contains tutorial material, but also feels like a more authoritative reference.

Most developers think reading about version control is a waste of their time (surely they should be reading about C# or Python or the latest webby thing instead?). I disagree with that - there is little point developing fantastic code if you then lose your greatest work because version control isn't being used correctly. However, I am also realistic about how much time most developers can be persuaded to spend reading about subjects such as version control. Therefore, I would suggest that most developers on a team using Subversion should read the Pragmatic book, as that will give them enough detail to do what they need to, but without being too long or being heavy to read. However, I think it is worth a couple of developers at each site spending the extra time required to also read "Version Control with Subversion" in order to sort out the organisation and practices to follow at that site, including development of any scripts that might be required to support those practices. "Version Control with Subversion" gives extra detail about the differences between version 1.4 and 1.5 of Subversion, more detail on the pros and cons of using properties, use of externals etc. Most developers don't need to know these things, but a few do.

So, a good book, a bit heavier to read than the Pragmatic book, but still worth the effort for those developers who need to get involved in version control a bit more deeply.