You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2008/03/28 14:57:03 UTC
svn log -g on repository root -- ouch
$ svn log --limit=25 http://svn.collab.net/repos/svn
real 0m2.014s
user 0m0.022s
sys 0m0.014s
$ svn log -g --limit=25 http://svn.collab.net/repos/svn
real 7m11.116s
user 0m0.023s
sys 0m0.013s
I do not know how bad it is hurting the server during all that time,
but the worst part is that the command output does not even contain
any merge information.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log -g on repository root -- ouch
Posted by Marc Strapetz <ma...@syntevo.com>.
> As for the lack of merge information, it would seem that mergeinfo isn't
> getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
> to provide that information, I suspect it's a problem with that API.
This is the same problem which has also been reported by me in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=135949 and
AFAICT it's still present in RC4. I couldn't find any issue regarding
this problem -- will it be addressed for the final 1.5 release?
--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Hyrum K. Wright wrote:
> Mark Phippard wrote:
>> $ svn log --limit=25 http://svn.collab.net/repos/svn
>> real 0m2.014s
>> user 0m0.022s
>> sys 0m0.014s
>>
>> $ svn log -g --limit=25 http://svn.collab.net/repos/svn
>> real 7m11.116s
>> user 0m0.023s
>> sys 0m0.013s
>>
>>
>> I do not know how bad it is hurting the server during all that time,
>> but the worst part is that the command output does not even contain
>> any merge information.
>
> One of the limitations of 'log -g' is that it traces the full history
> for the paths being examined, so that it can later determine branching
> information when tracing branch history. This is much akin to running
> 'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
> information before sending it. Running 'log -g' on the repo root causes
> this, as well as buffering for any merges created. I know it's ugly,
> but we need the history information so to determine when merges
> "re-attach" to a common line of history.
>
> As for the lack of merge information, it would seem that mergeinfo isn't
> getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
> to provide that information, I suspect it's a problem with that API.
> Dave, could you take a look at this?
>
> -Hyrum
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log -g on repository root -- ouch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Glasser wrote:
> On Fri, Mar 28, 2008 at 8:40 AM, Hyrum K. Wright
>> As for the lack of merge information, it would seem that mergeinfo isn't
>> getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
>> to provide that information, I suspect it's a problem with that API.
>> Dave, could you take a look at this?
>
> You are passing in TRUE for include_descendants, right?
Yes.
-Hyrum
Re: svn log -g on repository root -- ouch
Posted by David Glasser <gl...@davidglasser.net>.
On Fri, Mar 28, 2008 at 8:40 AM, Hyrum K. Wright
<hy...@mail.utexas.edu> wrote:
> Mark Phippard wrote:
> > $ svn log --limit=25 http://svn.collab.net/repos/svn
> > real 0m2.014s
> > user 0m0.022s
> > sys 0m0.014s
> >
> > $ svn log -g --limit=25 http://svn.collab.net/repos/svn
> > real 7m11.116s
> > user 0m0.023s
> > sys 0m0.013s
> >
> >
> > I do not know how bad it is hurting the server during all that time,
> > but the worst part is that the command output does not even contain
> > any merge information.
>
> One of the limitations of 'log -g' is that it traces the full history
> for the paths being examined, so that it can later determine branching
> information when tracing branch history. This is much akin to running
> 'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
> information before sending it. Running 'log -g' on the repo root causes
> this, as well as buffering for any merges created. I know it's ugly,
> but we need the history information so to determine when merges
> "re-attach" to a common line of history.
Wow. Is this the case even for looking at just one revision (ie, "svn
log -g -r123")?
> As for the lack of merge information, it would seem that mergeinfo isn't
> getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
> to provide that information, I suspect it's a problem with that API.
> Dave, could you take a look at this?
You are passing in TRUE for include_descendants, right?
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn log -g on repository root -- ouch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
C. Michael Pilato wrote:
> Hyrum K. Wright wrote:
>> Mark Phippard wrote:
>>> $ svn log --limit=25 http://svn.collab.net/repos/svn
>>> real 0m2.014s
>>> user 0m0.022s
>>> sys 0m0.014s
>>>
>>> $ svn log -g --limit=25 http://svn.collab.net/repos/svn
>>> real 7m11.116s
>>> user 0m0.023s
>>> sys 0m0.013s
>>>
>>>
>>> I do not know how bad it is hurting the server during all that time,
>>> but the worst part is that the command output does not even contain
>>> any merge information.
>>
>> One of the limitations of 'log -g' is that it traces the full history
>> for the paths being examined, so that it can later determine branching
>> information when tracing branch history. This is much akin to running
>> 'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
>> information before sending it. Running 'log -g' on the repo root
>> causes this, as well as buffering for any merges created. I know it's
>> ugly, but we need the history information so to determine when merges
>> "re-attach" to a common line of history.
>
> Are we walking the history with the svn_fs history APIs, or using the
> get_location_segments type of logic? Do we need to know every change
> along the way, or only "changes of address" points?
We're using the svn_fs history APIs, because we need to know which
revisions the mergeinfo changed in, as well as the log information for
any change revision. Maybe we could split the work up into different
passes over the history, but I don't know that that would help.
-Hyrum
Re: svn log -g on repository root -- ouch
Posted by "C. Michael Pilato" <cm...@collab.net>.
Hyrum K. Wright wrote:
> Mark Phippard wrote:
>> $ svn log --limit=25 http://svn.collab.net/repos/svn
>> real 0m2.014s
>> user 0m0.022s
>> sys 0m0.014s
>>
>> $ svn log -g --limit=25 http://svn.collab.net/repos/svn
>> real 7m11.116s
>> user 0m0.023s
>> sys 0m0.013s
>>
>>
>> I do not know how bad it is hurting the server during all that time,
>> but the worst part is that the command output does not even contain
>> any merge information.
>
> One of the limitations of 'log -g' is that it traces the full history
> for the paths being examined, so that it can later determine branching
> information when tracing branch history. This is much akin to running
> 'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
> information before sending it. Running 'log -g' on the repo root causes
> this, as well as buffering for any merges created. I know it's ugly,
> but we need the history information so to determine when merges
> "re-attach" to a common line of history.
Are we walking the history with the svn_fs history APIs, or using the
get_location_segments type of logic? Do we need to know every change along
the way, or only "changes of address" points?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn log -g on repository root -- ouch
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark Phippard wrote:
> $ svn log --limit=25 http://svn.collab.net/repos/svn
> real 0m2.014s
> user 0m0.022s
> sys 0m0.014s
>
> $ svn log -g --limit=25 http://svn.collab.net/repos/svn
> real 7m11.116s
> user 0m0.023s
> sys 0m0.013s
>
>
> I do not know how bad it is hurting the server during all that time,
> but the worst part is that the command output does not even contain
> any merge information.
One of the limitations of 'log -g' is that it traces the full history
for the paths being examined, so that it can later determine branching
information when tracing branch history. This is much akin to running
'svn log $REPOS_ROOT -r1:HEAD', which also buffers all the log
information before sending it. Running 'log -g' on the repo root causes
this, as well as buffering for any merges created. I know it's ugly,
but we need the history information so to determine when merges
"re-attach" to a common line of history.
As for the lack of merge information, it would seem that mergeinfo isn't
getting fetched for children. Since we rely on svn_fs_get_mergeinfo()
to provide that information, I suspect it's a problem with that API.
Dave, could you take a look at this?
-Hyrum