> From: Dylan Cuthbert [mailto:dylan@q-games.com]
>
> "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. :-)
>
Well, you do know what's been merged, and what generated conflicts.
However, you're not missing anything that no-conflict merges can cause
bugs to happen. Arbitrary text file merging can't prevent bugs like
this. It's just impossible.
Now if we were merging some kind of structured and internally consistent
data structure, you could certainly handle these things much more
sanely. Sadly, no commonly used programming languages are commonly
stored in such a format.
Bill
---------------------------------------------------------------------
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:51:43 2002