[svnbook] r4394 committed - Merge from ^/trunk/en r4392 (followup to r4387) and r4393 (new...
svnbook at googlecode.com
svnbook at googlecode.com
Mon Feb 4 14:42:09 CST 2013
Revision: 4394
Author: cmpilato at gmail.com
Date: Mon Feb 4 12:39:49 2013
Log: Merge from ^/trunk/en r4392 (followup to r4387) and r4393 (new
'To Branch or Not to Branch?' section).
http://code.google.com/p/svnbook/source/detail?r=4394
Modified:
/branches/1.7/en
/branches/1.7/en/book/ch00-preface.xml
/branches/1.7/en/book/ch04-branching-and-merging.xml
=======================================
--- /branches/1.7/en/book/ch00-preface.xml Fri Feb 1 10:44:07 2013
+++ /branches/1.7/en/book/ch00-preface.xml Mon Feb 4 12:39:49 2013
@@ -204,18 +204,22 @@
<para>There are pros and cons to each version control approach.
Perhaps the two biggest benefits delivered by the DVCS tools
- are incredible performance for day-to-day operations and
- vastly better support for merging between branches. The
- downside is that distribute version control is an inherently
+ are incredible performance for day-to-day operations (because
+ the primary data store is locally held) and vastly better
+ support for merging between branches (because merge algorithms
+ serve as the very core of how DVCSes work at all). The
+ downside is that distributed version control is an inherently
more complicated model, which can present a non-negligible
- challenge to comfortable collaboration. With centralized
- version control, you may find a greater degree of control over
- your versioned assets, especially as regards access control.
- Fortunately, many wise organizations have discovered that this
- needn't be a religious debate, and that Subversion and a DVCS
- tool such as Git can be used together harmoniously within the
- organization, each serving the purposes best suited to the
- tool.</para>
+ challenge to comfortable collaboration. Also, DVCS tools do
+ what they do well in part because of a certain degree of
+ control withheld from the user which centalized systems freely
+ offer—the ability to implement path-based access
+ control, the flexibility to update or backdate individual
+ versioned data items, etc. Fortunately, many wise
+ organizations have discovered that this needn't be a religious
+ debate, and that Subversion and a DVCS tool such as Git can be
+ used together harmoniously within the organization, each
+ serving the purposes best suited to the tool.</para>
<para>Alas, this book is about Subversion, so we'll not attempt
a full comparison of Subversion and other tools. Readers who
=======================================
--- /branches/1.7/en/book/ch04-branching-and-merging.xml Tue Jan 29
11:01:10 2013
+++ /branches/1.7/en/book/ch04-branching-and-merging.xml Mon Feb 4
12:39:49 2013
@@ -4044,6 +4044,112 @@
</sect2>
</sect1>
+ <!-- =================================================================
-->
+ <!-- =================================================================
-->
+ <!-- =================================================================
-->
+ <sect1 id="svn.branchmerge.when">
+ <title>To Branch or Not to Branch?</title>
+
+ <para>To branch or not to branch—that is an interesting
+ question. This chapter has provided thus far a pretty deep dive
+ into the waters of branching and merging, topics which have
+ historically been the premier source of Subversion user
+ confusion. As if the rote actions involved in branching and
+ branch management aren't sometimes tricky enough, some users get
+ hung up on deciding whether they need to branch at all. As
+ you've learned, Subversion can handle common branching and
+ branch management scenarios. So, the decision of whether or not
+ to branch a project's history is rarely a technical one.
+ Rather, the social impact of the decision often carries more
+ weight. Let's examine some of the benefits and costs of using
+ branches in a software project.</para>
+
+ <para>The most obvious benefit of working on a branch is
+ isolation. Changes made to the branch don't affect the other
+ lines of development in the project; changes made to those other
+ lines don't affect the branch. In this way, a branch can serve
+ as a great place to experiment with new features, complex bug
+ fixes, major code rewrites, and so on. No matter how much stuff
+ Sally breaks on her branch, Harry and the rest of the team can
+ continue with their work unhindered outside the branch.</para>
+
+ <para>Branches also provide a great way to organize related
+ changes into readily identifiable collections. For example, the
+ changes which comprise the complete solution to a particular bug
+ might be a list of non-sequential revision numbers. You might
+ describe them in human language as <quote>revisions 1534, 1543,
+ 1587 and 1588</quote>. You'd probably reproduce those numbers
+ manually (or otherwise) in the issue tracker artifact which
+ tracks the bug. When porting the bug fix to other product
+ versions, you'd need to make sure to port all those revisions.
+ But had those changes been made on a unique branch, you'd find
+ yourself referring only to that branch by its name in
+ conversation, in issue tracker comments, and when porting
+ changes.</para>
+
+ <para>The unfortunate downside of branches, though, is that the
+ very isolation that makes them so
+ useful <emphasis>can</emphasis> be at odds with the
+ collaborative needs of the project team. Depending on the work
+ habits of your project peers, changes made to branches might not
+ get the kind of constructive review, criticism, and testing that
+ changes made to the main line of development do. The isolation
+ of a branch can encourage users to forsake certain version
+ control <quote>best practices</quote>, leading to version
+ history which is difficult to review <foreignphrase>post
+ facto</foreignphrase>. Developers on long-lived branches
+ sometimes need to work extra hard to ensure that the
+ evolutionary direction of their isolated copy of the codebase is
+ in harmony with the direction their peers are steering the main
+ code lines. Now, these drawbacks might be less of an issue for
+ true exploratory branches aimed at experimenting with the future
+ of a codebase with no expectation of reintegrating the results
+ back into the main development lines—mere policy needn't
+ be a vision-killer! But the simple fact remains that projects
+ generally benefit from an orderly approach to version control
+ where code and code changes enjoy the review and comprehension
+ of more than one team member.</para>
+
+ <para>That's not to say that there are no technical penalties to
+ branching. Pardon us while we <quote>go meta</quote> for a bit
+ here. If you think about it, every time you checkout a
+ Subversion working copy, you're creating a branch of sorts of
+ your project. It's a special sort of branch. It lives only on
+ your client machine; not in the repository. You synchronize
+ this branch with changes made in the repository
+ using <command>svn update</command>—which acts almost like
+ a special-cased, simplified form of an <command>svn
+ merge</command> command.<footnote><para>Actually, you
+ <emphasis>could</emphasis> use <userinput>svn merge
+ -r<replaceable>LAST_UPDATED_REV</replaceable>:HEAD .</userinput>
+ in your working copy to quite literally merge in all the
+ repository changes since your last update if really wanted
+ to!</para></footnote> You effectively reintegrate your branch
+ each time you run <command>svn commit</command>. So, in that
+ special sense, Subversion users deal with branches and merges
+ all the time. Given the similarities between updating and
+ merging, it's no surprise, then, that the areas in which
+ Subversion seems to have the most shortcomings—namely,
+ handling file and directory renames and dealing with tree
+ conflicts in general—are problematic for both
+ the <command>svn update</command> and <command>svn
+ merge</command> operations. Unfortunately, <command>svn
+ merge</command> has a harder time of it precisely because of the
+ fact that, for every way in which <command>svn update</command>
+ is a special-cased, simplified kind of generic merge operation,
+ a true Subversion merge is neither special-cased nor simplified.
+ For this reason, merges perform much more slowly than updates,
+ require explicit tracking (via
+ the <literal>svn:mergeinfo</literal> property we've discussed in
+ this chapter) and history-crunching arithmetic, and generally
+ offer more opportunities for something to go awry.</para>
+
+ <para>To branch or not to branch? Ultimately, that depends on
+ what your team needs in order to find that sweet balance of
+ collaboration and isolation.</para>
+
+ </sect1>
+
<!-- =================================================================
-->
<!-- =================================================================
-->
<!-- =================================================================
-->
More information about the svnbook-dev
mailing list