Quoth Ward, Mark <mailto:MWard@netopia.com>:
> The svn merge command's output is showing a different number
> of updated files than are shown as modified by a svn status
> command executed immediately afterward. All of the files
> that are listed by merge, then not by status, are binary.
> The final results of the svn status command is what was
> expected and correct.
That's fairly normal when your branch already contains changes made in
the trunk.
> svn merge URL1 URL2 .
> U File1.bin
> U File2.bin
> U File3.bin
> U File3.src
This means that between those two URLs, those files were updated.
> svn status
> M File3.bin
> M File3.src
This means that as of now, only those files are different from your HEAD
revision.
> For context, the merge is from a bug fix branch into our
> production release which addressed File3.*. Prior to
> performing the merge, the bug fix branch was brought up to
> date with previous changes introduced into the production
> release (File1.bin and File2.bin) since the time of its
> original copying to check for conflicts and perform QA tests.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 7 03:42:10 2006