"Ben Collins-Sussman" <sussman@collab.net> wrote in message
news:86n0qr4bwv.fsf@kepler.ch.collab.net...
> "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
methodology.
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.
http://www.q-games.com
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