[Svnmerge] Behavior of the new 'svnmerge.py integrated' command

[Daniel Rall]

On Wed, 05 Apr 2006, Giovanni Bajo wrote:

> Blair Zajac <blair at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : /pipermail/svnmerge/attachments/20060406/f230c614/attachment.pgp