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

Behavior of the new 'svnmerge.py integrated' command

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-04-06 22:08:02 CEST

On Wed, 05 Apr 2006, Giovanni Bajo wrote:

> Blair Zajac <blair@orcaware.com> wrote:
>
> > $ /usr/bin/time ~/bin/svnmerge -s -v -v integrated
> > svn propget --strict "svnmerge-integrated" "."
> > svnmerge: calculate head path for the branch
> > svn info "."
> > svn info "http://svn/svn/repos/spijava/branches/blair"
> > svnmerge: head is "http://svn/svn/repos/spijava/trunk"
> > svn propget --strict "svnmerge-integrated" "."
> > svn log -r 1:HEAD --limit=1 -q .
> > svnmerge: available revisions to be merged are:
> > 40413-106349
>
> I'm confused as to why "svnmerge integrated" should ever run "svn log" (or even
> run any remote operation at all).

I don't think the code that's there ATM is quite right, because it's
looking for the oldest branch revision instead of the oldest source
(head) revision. However, the 'svn log' may still be needed for
correctness and/or consistency with 'svnmerge.py avail', because the
"svnmerge-integrated" property records more revisions in its revision
ranges than have actually been merged into a branch...

For example, consider a vanilla test case
(post-TestCase_TestRepo.setUp()) in svnmerge_test.py:

A propget of "svnmerge-integrated" on "test-branch/" has a value of
"trunk:/1-6" before any changes have merged from trunk into the branch
(but post-'init'). Considering that trunk wasn't even born until r3,
why should the 'integrated' command claim that revisions 1-6 had been
merged when in fact only 3-6 -- the birth of trunk through the
revision the branch was copied from trunk -- have actually been
(implicitly) "merged" into the branch?

Perhaps the storage format of the revision ranged used in the
"svnmerge-integrated" property is a simplifying assumption used by the
implementation 'svnmerge.py avail' to calculate the set of revisions
available (in this case, 9-10)? During some initial testing of the
patch for the in-the-works 'rollback' command, David James and I found
that we did want to ignore this set of "too old" changes during the
rollback process. However, perhaps this is not appropriate behavior
for 'integrated'...thoughts?

-- 
Daniel Rall

  • application/pgp-signature attachment: stored
Received on Thu Apr 6 22:08:55 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.