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

Re: svn commit: r30161 - in trunk/subversion: libsvn_ra_neon tests/cmdline

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 4 Apr 2008 14:47:06 -0700

On Fri, Apr 4, 2008 at 2:41 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
> > I was hoping that somebody with a better understanding of our DAV
> > report protocol could see if there are any other similar changes to be
> > made as well first.
>
> I think this change is spiffy (just reviewed), and you underestimate
> your understanding of the DAV protocol :-).
>
> You're right that we could open up "add-directory" to tolerate
> "delete-entry" too, but I'm wary of making a change that no bug report
> has called for yet. As you say, we don't send add-dir-with-history yet,
> and it seems to me that when we do, this either will or won't (but
> probably "will") be a problem, at which point we'll notice it. My
> instinct is to leave the rest alone right now, but if we do change it,
> let's keep the change in trunk and at least not backport it to 1.5
> (which, in theory, would never need it).

OK. Perhaps we should add a comment to the line in
libsvn_wc(!!!)/update_editor.c that whines if it gets an
add-dir-with-history saying "btw, if you enable this, there's this
subtle Neon issue to deal with too"?

And that report is absolutely 100% *only* used by the repos-reporter?
That code is never triggered for, say, a replay report (which I
suppose has its own completely redundant "parse an editor drive out of
XML" code)?

--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-04-04 23:47:17 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.