On Wed, 09 May 2007, Ben Collins-Sussman wrote:
> Hi guys, I'm trying to figger out what our merge-tracking code is and
> isn't capable of. I'm also starting to work on making our
> notification system deal with 'multiple notifications' of subsequently
> merged ranges of revisions.
This is expected to work. I'm also seeing weird output from your test
case.
> Just to get my feet wet, I wrote a short shell script. The script
> does a bunch of commits to a branch. It cherrypicks one change and
> ports it from branch to trunk, then tries to just 'merge everything
> else' by magic (svn merge BRANCHURL trunk-wc).
>
> My expectation is that the magic-merge should do merge two distinct
> ranges of changes -- those before my cherrypicked change, and those
> after. However, my output is bizarre... lots of additions, conflicts,
> and so on. I need a sanity check, or a does of expectation
> management. :-)
Your expectation is correct. I see do_merge() calculating the correct
revision range. However, something is going wonky. I noticed that
their appears to be merge info in the tree below the level of the
merge (so-called "sub-tree merge info"); I wonder if that is
responsible...
- Dan
- application/pgp-signature attachment: stored
Received on Wed May 9 23:50:10 2007