On Tuesday 01 March 2011 06:30 PM, stsp_at_apache.org wrote:
> Author: stsp
> Date: Tue Mar 1 13:00:47 2011
> New Revision: 1075802
>
> URL: http://svn.apache.org/viewvc?rev=1075802&view=rev
> Log:
> Fix issue #3686 - executable bit not set during merge.
>
> The cause was the special case in libsvn_client, which bypassed the use of
> the workqueue. This logic has now been moved into libsvn_wc.
>
> Additionally, this change allows the status of binary files (during a
> dry-run merge) to be reported correctly (previously, all binary files
> were reported as conflicted).
>
> * subversion/libsvn_client/merge.c
> (merge_file_changed): Remove binary-merge special case (now in libsvn_wc).
> Remove merge_required variable (resulting in indentation changes).
>
> * subversion/libsvn_wc/merge.c
> (merge_binary_file): Add dry_run parameter. Add the special case merging
> of binary files.
> (svn_wc__internal_merge): Remove dry_run check for binary files, and pass
> to merge_binary_file instead.
>
> * subversion/tests/cmdline/merge_tests.py
> (merge_change_to_file_with_executable): Remove @XFail decorator.
>
>
> Patch by: Daniel Becroft<djcbecroft_at_gmail.com>
>
> Modified:
> subversion/trunk/subversion/libsvn_client/merge.c
> subversion/trunk/subversion/libsvn_wc/merge.c
> subversion/trunk/subversion/tests/cmdline/merge_tests.py
Post this fix, I noticed that **merge --dry-run** throws an interactive
conflict resolution dialog and create the merge-left and merge-right files.
This alters the Working Copy (creating filename.merge-left.rXYZ,
filename.merge-right.rABC) without marking a conflict (because it's a
dry-run). the test-case attached to the issue, only tests for the
executable flag. It doesn't run_and_verify_merge (which would make sure
the dry-run doesn't alter the Working Copy.)
Now this poses an issue when the conflicting file is marked conflicted
by some other operation.
This other operation will create two files (
filename._/*2*/_.merge-left.rXYZ, filename._/*2*/_.merge-right.rDEF ).
Currently, the resolve is reading from the highest numbered set of files
(I think).
As a side-effect of this experiment, I noticed this :
Removing these files causes the node to lose it's conflict state (why
should the status command rely on the presence/absence of conflict
resolution files to display the status).
Regards,
Arwin Arni
Received on 2011-03-04 11:59:41 CET