[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Fwd: svn1.5 seems to fail simple merge-tracking scenario

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 11 Jun 2009 16:21:51 -0400

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
> trunk:2-115
> branches/foo>svn merge --record-only -c 300 ^/trunk
> branches/foo>svn pg svn:mergeinfo | grep trunk
> trunk:300
> 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
this document:


Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-11 22:22:52 CEST

This is an archived mail posted to the Subversion Users mailing list.