[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1075802 - in /subversion/trunk/subversion: libsvn_client/merge.c libsvn_wc/merge.c tests/cmdline/merge_tests.py

From: Arwin Arni <arwin_at_collab.net>
Date: Fri, 04 Mar 2011 16:29:06 +0530

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).

Arwin Arni
Received on 2011-03-04 11:59:41 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.