Re: svn commit: r19110 - trunk/contrib/client-side

[Blair Zajac <bl...@orcaware.com>]

dlr@tigris.org wrote:
> Author: dlr
> Date: Fri Mar 31 10:16:17 2006
> New Revision: 19110
> 
> Modified:
>    trunk/contrib/client-side/svnmerge.py
>    trunk/contrib/client-side/svnmerge_test.py
> 
> Log:
> Add a new 'svnmerge.py integrated' command, which tells you which
> change sets have been merged into a branch (the inverse of 'avail').
> 
> This is a precursor to implementation of the 'rollback' command, which
> requires some of the functionality of 'integrated' command, and
> facilitates smoother usability (since you'll often run 'integrated' to
> figure out what revisions to 'rollback').

I just tried the new version and got this output.

$ /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
200.51user 1.21system 3:40.93elapsed 91%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+13592minor)pagefaults 0swaps


A couple of things.

1) The message 'available revisions to be merged are' is confusing, given that I 
ran the integrated command.  It should say which revisions were integrated.

2) It took a lot of CPU time and clock time (over 3 minutes).  After it runs the

svn log -r 1:HEAD --limit=1 -q .

there's no visible indication of what the script is doing.  I assumed that it 
was stuck in the response from the svn log, but it turns out that that returns 
in a couple of second, so that's not the cause.

It would be good to have an additional message stating what its doing then.

Regards,
Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Daniel Rall <dl...@collab.net>]

On Thu, 06 Apr 2006, Daniel Rall wrote:

> On Wed, 05 Apr 2006, Giovanni Bajo wrote:
...
> > 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.

Back from a brief vacation, I had time to glance over this today with
David James.  This was indeed a bug in 'integrated', fixed in r19337
of Subversion's trunk.

> 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?

I've seen no comments on this, so I left the implementation as-is,
*not* claiming that revisions which predate the source URL have been
integrated into the destination WC.

While passing the output of 'integrated' to 'svnmerge.py rollback' or
'svn' probably would work fine, I dislike the tool claiming that it's
merged revisions which it couldn't possibly have merged.  The cost of
one 'svn log' operation seems like a reasonable trade-off here.


> Dan wrote:
> 
> > Blair wrote:
...
> > 2) It took a lot of CPU time and clock time (over 3 minutes).  After it 
> > runs the
> > 
> > svn log -r 1:HEAD --limit=1 -q .
> > 
> > there's no visible indication of what the script is doing.  I assumed that 
> > it was stuck in the response from the svn log, but it turns out that that 
> > returns in a couple of second, so that's not the cause.
> > 
> > It would be good to have an additional message stating what its doing then.
> 
> I suspect that the extra time may be due to subtracting the
> revisions which predate the branch (svnmerge.py at 19195, line
> 1011), ...

This turned out to be the cause of the slowness, which was caused by
passing a list to RevisionSet.__sub__().  Changing this to pass a
revision set -- also in r19337 -- improved performance by operating on
a dict instead of a list.
-- 

Daniel Rall

Behavior of the new 'svnmerge.py integrated' command

[Daniel Rall <dl...@collab.net>]

On Wed, 05 Apr 2006, Giovanni Bajo wrote:

> Blair Zajac <bl...@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

Re: [Svnmerge] Re: svn commit: r19110 - trunk/contrib/client-side

[Giovanni Bajo <ra...@develer.com>]

Blair Zajac <bl...@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).

Giovanni Bajo


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r19110 - trunk/contrib/client-side

[Daniel Rall <dl...@collab.net>]

On Wed, 05 Apr 2006, Blair Zajac 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
> 200.51user 1.21system 3:40.93elapsed 91%CPU (0avgtext+0avgdata 
> 0maxresident)k
> 0inputs+0outputs (0major+13592minor)pagefaults 0swaps
> 
> 
> A couple of things.
> 
> 1) The message 'available revisions to be merged are' is confusing, given 
> that I ran the integrated command.  It should say which revisions were 
> integrated.
> 
> 2) It took a lot of CPU time and clock time (over 3 minutes).  After it 
> runs the
> 
> svn log -r 1:HEAD --limit=1 -q .
> 
> there's no visible indication of what the script is doing.  I assumed that 
> it was stuck in the response from the svn log, but it turns out that that 
> returns in a couple of second, so that's not the cause.
> 
> It would be good to have an additional message stating what its doing then.

Blair, thanks a lot for kicking the tires.  I've updated the output
when in verbose mode in r19195 for both #1 and #2.

I suspect that the extra time may be due to subtracting the revisions
which predate the branch (svnmerge.py@19195, line 1011), code which I
now believe may not even be correct for the 'integrated' command.  I
may've conflated my thoughts with implementation of the 'rollback'
command (Giovanni as alluded to as much in his follow-up comment about
"why are you even running log?").

I'll investigate that this week.

Thanks, Dan