> So, as I said before, what's happened is that the merge reapplied
changes in those
> files that already existed in your branch, and as a result the final
files are
> identical to what you had (in your branch) before, and hence not
listed as modified.
> As an experiment, try modifying a versioned and unmodified file (text
or binary, it
> doesn't matter), saving it, and then running 'svn st'. It will show
the file with an
> M flag. Now try modifying it back to how it was before (without
explicitly reverting
> it) and saving it again, then rerunning 'svn st'. The M flag has gone
away, because
> the file contents are now identical -- even though you've modified it
twice.
Thank you for this. It provides some relief knowing that the behavior
is as expected. Our group is just coming up to speed with subversion
and is only now merging changes sets of any consequence or complexity --
so far so good.
I still do hold some confusion as to why, given all that the merge
command must know at the time of its running, it can't determine that
the files it's marked for merger are identical to the working copy and
ignore them in its reporting.
For example, I recently ran the merge command with --dry-run and it
reported conflicts with the working copy. If merge can know about a
conflict in advance, why can't it know that a reapplication will have no
net change and ignore it in its output? I feel I understand fully the
experiment you outlined, but do not see clearly how to map it to the
merge command.
Many thanks,
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 10 03:24:56 2006