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

Re: Question regarding merging branches

From: Dylan Cuthbert <dylan_at_q-games.com>
Date: 2002-09-10 03:41:14 CEST

"Ben Collins-Sussman" <sussman@collab.net> wrote in message
> "Dylan Cuthbert" <dylan@q-games.com> writes:
> >
> > What am I not "getting"?
> Here's what you're not getting: a "conflict" is defined to be a clash
> between
> 1. a patch that the server is trying to apply to a file
> 2. a local mod that you have made to the file.
> In your examples, you have *no* local mods when you run 'svn merge', so
> you will never ever see a conflict. The patch from the server will
> always be applied cleanly.
> Conflicts happen only when there's risk of permanently losing changes;
> but because you commit everything, that risk is gone.
> To get a conflict, try changing the first line to something new,
> *don't* commit, and run 'svn merge' from the branch to the trunk.

Ok, I understand what you're saying but I'm not sure I agree with the

It seems that this kind of patching will generate bugs because it is
"piecemeal". ie. parts of the file get updated because there's no clash, and
other parts don't because there is. However, the parts that do get updated
might rely on the changes in the clashing parts. (as they are all in the
same file)

I understand that no data gets lost, but when merging a branch with, say,
100 files or more, all of which have committed changes, some conflicting,
some not, I end up with no idea what's been merged and what hasn't. This
seems very error-prone.

Or maybe there's some subtlety that I'm missing again. :-)

Q-Games, Dylan Cuthbert.
P2P internet radio - http://www.peercast.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 10 03:45:06 2002

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

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