Merge Command Output Different from Status Output

["Ward, Mark" <MW...@netopia.com>]

svn version 1.3.0 (r17949)

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.

svn merge URL1 URL2 .
U      File1.bin
U      File2.bin
U      File3.bin
U      File3.src

svn status
M      File3.bin
M      File3.src

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.

What is the reason for the difference in the output of these two
commands?  
Is it something unique to binary file types?
Is there a verbose mode on the merge to understand better how its logic
is being applied?

Please let me know what, if any, additional information I might provide
to help illumniate this issue such as providing logs, revision numbers,
etc. at the various steps and stages.

Cheers,
Mark








---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Merge Command Output Different from Status Output

[Gavin Lambert <ga...@compacsort.com>]

Quoth Ward, Mark <ma...@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