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

Re: [PATCH] First crack at issue 571

From: Chris AtLee <catlee_at_sidefx.com>
Date: 2004-11-24 21:02:42 CET

On Sun, 2004-21-11 at 19:44 +0100, Branko ╚ibej wrote:
> Are you certain that when a path is being replaced, the "D" will always
> immediately follow the "A"? If it doesn't, your solution won't work.
> Look at r1378 that's mentioned in that issue; Garrett used a hash table
> to avoid this very problem.

Granted, I don't understand the code very well, but it seems to me that
update_entry() in libsvn_repos/reporter.c guarantees that this order
will take place. editor->delete_entry() is called if necessary followed
by a call to editor->add_file().

> >Index: subversion/clients/cmdline/notify.c
> >===================================================================
> >--- subversion/clients/cmdline/notify.c (revision 11937)
> >+++ subversion/clients/cmdline/notify.c (working copy)
> >@@ -47,6 +47,7 @@
> > when we've already had one print error. */
> > apr_pool_t *pool; /* this pool is cleared after every notification,
> > so don't keep anything here! */
> >+ svn_string_t* deleted_path; /* What was the path that was deleted? */
> >
> >
> You don't need an svn_string_t* here. A const char* (copied into the
> temporary pool) will do nicely, since you're not concatenating to the
> string or anything.

Ok, no problem...And I'll fix up the formatting / alignment as well.

> >@@ -358,7 +392,10 @@
> > break;
> > }
> >
> >- svn_pool_clear (nb->pool);
> >+ /* If we're not keeping track of the deleted_path, then we can
> >+ * clear the pool. */
> >+ if (nb->deleted_path == NULL)
> >+ svn_pool_clear (nb->pool);
> > return;
> >
> >
> What else is in that pool? How large can it grow?

The pool was originally cleared every time the notification was done.
It is used for all the svn_cmdline_printf calls, as well as a call to
svn_path_local_style. I'm not sure what the upper bound on its size is,
but my change potentially multiplies that upper bound by the number of
consecutive delete notifications since the pool doesn't get cleared when
a delete notification is received. I could add a call to clear the pool
just before the "D" is printed out so that the pool does get cleared at
least every 2 times notify is called.

Cheers,
Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 24 21:04:14 2004

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