You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2008/01/09 16:39:12 UTC

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

On Jan 8, 2008 9:00 PM,  <kf...@tigris.org> wrote:
> Author: kfogel
> Date: Tue Jan  8 18:00:15 2008
> New Revision: 28816
>
> Log:
> On the reintegrate branch:
>
> * subversion/tests/cmdline/merge_tests.py
>   (reintegrate_fail_on_stale_source): New test.
>   (test_list): Run it XFail.
>
>
> Modified:
>    branches/reintegrate/subversion/tests/cmdline/merge_tests.py
>
> Modified: branches/reintegrate/subversion/tests/cmdline/merge_tests.py
> URL: http://svn.collab.net/viewvc/svn/branches/reintegrate/subversion/tests/cmdline/merge_tests.py?pathrev=28816&r1=28815&r2=28816
> ==============================================================================
> --- branches/reintegrate/subversion/tests/cmdline/merge_tests.py        (original)
> +++ branches/reintegrate/subversion/tests/cmdline/merge_tests.py        Tue Jan  8 18:00:15 2008
> @@ -9958,6 +9958,25 @@
>      ".*Cannot reintegrate into a working copy not.*at infinite depth.*",
>      None, None, None, None, True, False, '--reintegrate')
>
> +def reintegrate_fail_on_stale_source(sbox):
> +  "merge --reintegrate should fail on stale source"
> +  sbox.build()
> +  wc_dir = sbox.wc_dir
> +  expected_disk, expected_status = set_up_branch(sbox)
> +  A_path = os.path.join(wc_dir, "A")
> +  mu_path = os.path.join(A_path, "mu")
> +  svntest.main.file_append(mu_path, 'some text appended to mu\n')
> +  svntest.actions.run_and_verify_svn(None, None, [], 'commit',
> +                                     '-m', 'a change to mu', mu_path);
> +  # Unmix the revisions in the working copy.
> +  svntest.actions.run_and_verify_svn(None, None, [], 'update', wc_dir);
> +  # The merge --reintegrate should fail because target has changes not
> +  # present in source.
> +  svntest.actions.run_and_verify_merge(
> +    A_path, None, None, sbox.repo_url + '/A_COPY', None, None, None, None,
> +    ".*", ###TODO(reint): need a more specific check here
> +    None, None, None, None, True, False, '--reintegrate')
> +
>
>  ########################################################################
>  # Run the tests
> @@ -10052,6 +10071,7 @@
>                reintegrate_fail_on_mixed_rev_wc,
>                reintegrate_fail_on_switched_wc,
>                reintegrate_fail_on_shallow_wc,
> +              XFail(reintegrate_fail_on_stale_source),
>               ]

Wait, really?  The target may have more changes, but they all are at
"the end".  --reintegrate should choose the left-hand URL to be the
copy source of the branch, and successfully merge the (lack of)
changes from the branch to the target.

(Also, you need to merge-kluge here, right?)

--dave

-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> On Jan 9, 2008 2:51 PM, Karl Fogel <kf...@red-bean.com> wrote:
> Yes, this should work (now, even).  The logic is essentially "is the
> set of revisions merged to the branch a prefix of the revisions
> committed to the target?  if so, choose a left-hand-side equal to the
> point where the prefix stops".  See calculate_left_hand_side.

Okay, then I'll test that.  Thanks!

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

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

Posted by David Glasser <gl...@davidglasser.net>.
On Jan 9, 2008 3:00 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
> > Yes, this should work (now, even).  The logic is essentially "is the
> > set of revisions merged to the branch a prefix of the revisions
> > committed to the target?  if so, choose a left-hand-side equal to the
> > point where the prefix stops".  See calculate_left_hand_side.
>
> Btw, the reason I wasn't straight in my head about this was that I'd
> still been thinking of --reintegrate as doing "swap in the branch tip
> to replace the trunk tip, because the branch contains everything the
> trunk does".  That was the base case that originally motivated our
> --reintegrate thinking, but we've gotten well beyond that now, and as
> a result, what we do can no longer be described as a simple swap-in.
>
> I'm saying this here partly as a sanity check.  If the above doesn't
> make sense to you, then I'm worried :-).

Yup.  I think we basically decided that this extra case was both easy
to support and (as argued by Mark) pretty useful too.

--dave


-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> Yes, this should work (now, even).  The logic is essentially "is the
> set of revisions merged to the branch a prefix of the revisions
> committed to the target?  if so, choose a left-hand-side equal to the
> point where the prefix stops".  See calculate_left_hand_side.

Btw, the reason I wasn't straight in my head about this was that I'd
still been thinking of --reintegrate as doing "swap in the branch tip
to replace the trunk tip, because the branch contains everything the
trunk does".  That was the base case that originally motivated our
--reintegrate thinking, but we've gotten well beyond that now, and as
a result, what we do can no longer be described as a simple swap-in.

I'm saying this here partly as a sanity check.  If the above doesn't
make sense to you, then I'm worried :-).

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

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

Posted by David Glasser <gl...@davidglasser.net>.
On Jan 9, 2008 2:51 PM, Karl Fogel <kf...@red-bean.com> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
> > Wait, really?  The target may have more changes, but they all are at
> > "the end".  --reintegrate should choose the left-hand URL to be the
> > copy source of the branch, and successfully merge the (lack of)
> > changes from the branch to the target.
>
> Ah, right.  But I'm planning to put some changes onto the branch.
> Would 'merge --reintegrate' then still succeed?  That is, were we
> smart enough to have reintegrate look for a revision along the target
> line with respect to which the source is "up to date", and use that
> revision instead of HEAD?

Yes, this should work (now, even).  The logic is essentially "is the
set of revisions merged to the branch a prefix of the revisions
committed to the target?  if so, choose a left-hand-side equal to the
point where the prefix stops".  See calculate_left_hand_side.

--dave


-- 
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/

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

Re: svn commit: r28816 - branches/reintegrate/subversion/tests/cmdline

Posted by Karl Fogel <kf...@red-bean.com>.
"David Glasser" <gl...@davidglasser.net> writes:
> Wait, really?  The target may have more changes, but they all are at
> "the end".  --reintegrate should choose the left-hand URL to be the
> copy source of the branch, and successfully merge the (lack of)
> changes from the branch to the target.

Ah, right.  But I'm planning to put some changes onto the branch.
Would 'merge --reintegrate' then still succeed?  That is, were we
smart enough to have reintegrate look for a revision along the target
line with respect to which the source is "up to date", and use that
revision instead of HEAD?

In general, there's some fuzziness around the question of which
reintegrations should succeed and which should fail.  Feel free to
suggest tests; I'm happy to write them.  I'm trying to come up with a
list of obvious tests right now.

> (Also, you need to merge-kluge here, right?)

No, actually I think all the Merge Kluge stuff is obsolete now -- the
issues that required it are long closed.  When I get a chance I'd like
to take Merge Kluge out entirely and see if everything still works.

Thanks for the review!

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