Version Control with Subversion - Login

Branching and Mergingternal concept of a branch—it knows only how to make copies. When you copy a directory,the resultant directory is only a “branch” because you attach that meaning to it. You maythink of the directory differently, or treat it differently, but to Subversion it's just an ordinarydirectory that happens to carry some extra historical information.Second, because of this copy mechanism, Subversion's branches exist as normal filesystemdirectories in the repository. This is different from other version control systems, wherebranches are typically defined by adding extra-dimensional “labels” to collections of files.The location of your branch directory doesn't matter to Subversion. Most teams follow aconvention of putting all branches into a /branches directory, but you're free to invent anypolicy you wish.Basic MergingNow you and Sally are working on parallel branches of the project: you're working on aprivate branch, and Sally is working on the trunk, or main line of development.For projects that have a large number of contributors, it's common for most people to haveworking copies of the trunk. Whenever someone needs to make a long-running changethat is likely to disrupt the trunk, a standard procedure is to create a private branch andcommit changes there until all the work is complete.So, the good news is that you and Sally aren't interfering with each other. The bad news isthat it's very easy to drift too far apart. Remember that one of the problems with the “crawlin a hole” strategy is that by the time you're finished with your branch, it may be nearimpossibleto merge your changes back into the trunk without a huge number of conflicts.Instead, you and Sally might continue to share changes as you work. It's up to you to decidewhich changes are worth sharing; Subversion gives you the ability to selectively“copy” changes between branches. And when you're completely finished with your branch,your entire set of branch changes can be copied back into the trunk. In Subversion terminology,the general act of replicating changes from one branch to another is called merging,and it is performed using various invocations of the svn merge command.In the examples that follow, we're assuming that both your Subversion client and server arerunning Subversion 1.5 (or later). If either client or server is older than version 1.5, thingsare more complicated: the system won't track changes automatically, and you'll have touse painful manual methods to achieve similar results. That is, you'll always need to usethe detailed merge syntax to specify specific ranges of revisions to replicate (see the sectioncalled “Merge Syntax: Full Disclosure” later in this chapter), and take special care tokeep track of what's already been merged and what hasn't. For this reason, we strongly recommendthat you make sure your client and server are at least at version 1.5.ChangesetsBefore we proceed further, we should warn you that there's going to be a lot of discussionof “changes” in the pages ahead. A lot of people experienced with version control systemsuse the terms “change” and “changeset” interchangeably, and we should clarify what Subversionunderstands as a changeset.Everyone seems to have a slightly different definition of changeset, or at least a differentexpectation of what it means for a version control system to have one. For our purposes,let's say that a changeset is just a collection of changes with a unique name. The changesmight include textual edits to file contents, modifications to tree structure, or tweaks tometadata. In more common speak, a changeset is just a patch with a name you can referto.In Subversion, a global revision number N names a tree in the repository: it's the way therepository looked after the Nth commit. It's also the name of an implicit changeset: if youcompare tree N with tree N#1, you can derive the exact patch that was committed. For this91