On Fri, Mar 28, 2008 at 8:40 AM, Hyrum K. Wright
<hyrum_wright_at_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_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-28 17:08:20 CET