[PATCH][merge-tracking] Fix for failing testcase merge-tests.py:35

[Kamesh Jayachandran <ka...@collab.net>]

Hi All,
Find the attached patch and log to make 35th tests on merge-tests.py 
tests to pass on merge-tracking branch.

Not sure whether it is the right approach for the following 2 reasons,
1. Should we record the mergeinfo in case of conflicting merges?
2. Should'nt we check for historical relation ships between source and 
destination before recording mergeinfos?

With regards
Kamesh Jayachandran

Re: [PATCH][merge-tracking] Fix for failing testcase merge-tests.py:35

[Kamesh Jayachandran <ka...@collab.net>]

Can someone look into this?

With regards
Kamesh Jayachandran
Kamesh Jayachandran wrote:
> Hi All,
> Find the attached patch and log to make 35th tests on merge-tests.py 
> tests to pass on merge-tracking branch.
>
> Not sure whether it is the right approach for the following 2 reasons,
> 1. Should we record the mergeinfo in case of conflicting merges?
> 2. Should'nt we check for historical relation ships between source and 
> destination before recording mergeinfos?
>
> With regards
> Kamesh Jayachandran
>
> ------------------------------------------------------------------------
>
> [[[
> Patch by: Kamesh Jayachandran <ka...@collab.net>
>
> Fix 'merge_add_over_versioned_file_conflicts' testcase taking care of 
> 'merge-tracking' implementation.
>
> * subversion/tests/cmdline/merge_tests.py
>   (merge_add_over_versioned_file_conflicts):
>    Expect to have 'prop modified'
> ]]]
>   
> ------------------------------------------------------------------------
>
> Index: subversion/tests/cmdline/merge_tests.py
> ===================================================================
> --- subversion/tests/cmdline/merge_tests.py	(revision 21450)
> +++ subversion/tests/cmdline/merge_tests.py	(working copy)
> @@ -3637,7 +3637,7 @@
>      'beta'    : Item("This is the file 'beta'.\n"),
>      })
>    expected_status = wc.State(short_E_path, {
> -    ''       : Item(status='  ', wc_rev=1),
> +    ''     : Item(status=' M', wc_rev=1),
>      'alpha'  : Item(status='C ', wc_rev=1),
>      'beta'   : Item(status='  ', wc_rev=1),
>      })
>
>   
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

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

Re: [PATCH][merge-tracking] Fix for failing testcase merge-tests.py:35

[Daniel Rall <dl...@collab.net>]

On Tue, 12 Sep 2006, Kamesh Jayachandran wrote:
...
> 1. Should we record the mergeinfo in case of conflicting merges?

In merge-tracking/TODO, we said the following:

    * If a conflict is encountered, invoke a conflict resolution
      callback to give a Subversion client a chance to intervene.  If
      resolution is successful, convert the notification from a 'C' to
      something else (e.g. 'M').  (Phase 2?)

    * Otherwise, stop applying merge ranges as soon as a second
      conflict is encountered in a WC item (as it might generate
      overlapping conflict makers, or apply a merge inside a conflict
      marker!), being sure to record partial application of merge
      ranges.

So for merge test #35, we should record merge info the conflict, as
only one occurs in a WC item (as per your patch).

> 2. Shouldn't we check for historical relationships between source
> and destination before recording merge info?

No.  Subversion has never required a historical relationship to exist
between merge source and target -- merging two pieces of unrelated
text together is perfectly fine.  I don't see any reason to adopt this
requirement for Merge Tracking.


I've tweaked the formatting of your patch and committed it as r21525.
Thanks Kamesh!

- Dan