[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Could merging be any more cumbersome?

From: Rick Mann <rmann_at_latencyzero.com>
Date: 2005-08-05 22:19:59 CEST

On Aug 5, 2005, at 5:53 AM, Ben Collins-Sussman wrote:

> Where does the book say that's the "wrong way" to think about it?

Well, perhaps it doesn't say it's "wrong," but it points out that
most new users think about merge one way, and svn thinks about it
another. Rereading it now I guess I, too, misunderstood what the
manual was saying:

> The Key Concept Behind Merging
> You've now seen an example of the svn merge command, and you're
> about to see several more. If you're feeling confused about exactly
> how merging works, you're not alone. Many users (especially those
> new to version control) are initially perplexed about the proper
> syntax of the command, and about how and when the feature should be
> used. But fear not, this command is actually much simpler than you
> think! There's a very easy technique for understanding exactly how
> svn merge behaves.
> The main source of confusion is the name of the command. The term
> “merge” somehow denotes that branches are combined together, or
> that there's some sort of mysterious blending of data going on.
> That's not the case. A better name for the command might have been
> svn diff-and-apply, because that's all that happens: two repository
> trees are compared, and the differences are applied to a working copy.
I never did think merging somehow combined branches. But I do think
of merging as making one branch identical to another.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 5 22:23:07 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.