On Thu, Jun 11, 2009 at 3:51 PM, Trent Nelson<tnelson_at_onresolve.com> wrote:
> Eek. We've been using the --record-only -r0:100 pattern for the last few months. It seemed to work fine, initially. Only in the last week or two has it become apparent that the last 50+ re-integrations/syncs have almost all been subtlety borked. And in some cases, not so subtlety -- the epic-fail-upon-any-form-of-merge branches are what alerted us to the underlying issue that's been secretly haunting us since we clocked revision ~73 or so, in March-ish.
> But, for now, I digress. I've just played around with a couple of re-integrations/syncs using -c 100 instead of -r0:100. This behaviour surprised me:
> branches/foo>svn pg svn:mergeinfo . | grep trunk
> branches/foo>svn merge --record-only -c 300 ^/trunk
> branches/foo>svn pg svn:mergeinfo | grep trunk
> I was expecting to see `trunk:2-115,300`, not `trunk:300`. The latter just doesn't seem right; or am I incorrectly expecting svn:mergeinfo to mirror the semantics of svnmerge-integrated/svnmerge-blocked?
The format of svn:mergeinfo is different. A branch should not contain
any of its "natural history". In other words if you copied trunk_at_115
to create the branch, then the branch already knows that it includes
those revisions from trunk and it should not include it in the
mergeinfo. It would be expected to only see r300 if that is the only
revision that has been merged to the branch.
See the section titled "Natural History and Implicit Mergeinfo" in
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-11 22:22:52 CEST