Hi,
That is what the starting point of issue 2897.
*It just does *avoid repeat merge* wrongly. See desc1 of issue 2897. The
issue-2897 address that problem, if you take it should work(I am
reworking on the API to fix few edge case, after this extraction of
non-merge changes would be the next major task).
With regards
Kamesh Jayachandran
Ben Collins-Sussman wrote:
> I'm in the process of documenting basic merge tracking in the svnbook,
> describing the basic process of managing a long-lived feature branch
> and then merging it back to trunk. In the process, I've been
> experimenting with (today's) trunk code, testing out the famed
> 'reflective merge' scenario by hand.
>
> I'm using ra_local. I made a trunk, did some commits. Copied trunk
> to branch. Then started making commits on both trunk and branch, back
> and forth. As expected, 'svn merge trunkURL' in my branch-wc just did
> the right thing. I did a bunch more commits to both trunk and branch,
> and once again, 'svn merge trunkURL' did the right thing. (It's really
> nice to have repeated branch synchronization so easy!)
>
> What's weird is when I tried to merge the branch back to trunk.
> First, I made sure the branch was entirely synchronized with the
> trunk. Then I went into my trunk-wc and tried to preview the merge:
>
> $ svn mergeinfo . --from-source
> file:///Users/sussman/scratch/repos/branches/mybranch
> Path: .
>
> $
>
> Wha? Nothing at all pending? No candidate ranges?
>
> When I did the 'reflective' merge itself, I got nothing as well:
>
> $ svn merge file:///Users/sussman/scratch/repos/branches/mybranch .
> --- Merging r19 into '.':
> U .
>
> $ svn diff
>
> Property changes on: .
> ___________________________________________________________________
> Added: svn:mergeinfo
> Merged /trunk:r16-18
> Merged /branches/mybranch:r19
>
>
> ...this makes no sense to me. The branch's mergeinfo is correct, I
> think:
>
> $ svn pl -v mybranch/
> Properties on 'mybranch':
> svn:mergeinfo : /trunk:5-18
>
> But I *know* there are a whole bunch of changes on the branch, and it
> seems like the reflective merge should be aware of them.
>
> Am I using this feature incorrectly? Are we waiting for Kamesh's
> feature to be done? (I thought Kamesh's work was to separate
> conflict-fix changes from normal merge changes... and none of my
> merges had any conflicts.)
>
> I've attached my dumpfile for reference.
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> 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
Received on Mon Dec 10 07:56:43 2007