Mark Phippard wrote:
> On Sat, Dec 6, 2008 at 2:49 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> Mark Phippard wrote:
>>> Just to follow-up, this problem still happens in trunk. I have
>>> attached a patch to the JavaHL tests that causes the breakage. I also
>>> looked into the NotifyInformation class and there is no way to fix
>>> this problem in that class as the error occurs in a base class from
>>> the JDK that it inherits from.
>>> I can commit the patch but it causes breakage. I thought it might be
>>> easier to just give to someone that is willing to look into the
>> The attached patch fixes the problem locally by setting the commit item path to
>> the same value as the url. The result will be the url being passed as the path
>> parameter to the notification callback. Do we do that for the other items in a
>> wc-to-url copy, or are the notification paths some sort of relative path?
> It looks like you asked what my concerns were to this patch on IRC.
> My concern was mainly that I questioned whether it was valid to send a
> URL to that notification in the path field. It might be valid, the
> JavaDoc for the class does not really say. Given how I know we use
> this field in Subclipse, I believe we expect to receive local paths.
> That said, if SVN already sends URL's in other places, then we likely
> already have code to handle this.
> I asked if we needed to send this notification at all. It does not
> seem to be adding anything of value for an API consumer so why send
Well, I forget what we do on the command line for 'svn cp --parents $WCPATH
$URL', but I don't think we just ignore the parent notifications. We ought to
be doing the same thing in JavaHL which we are doing on the command line, IMHO.
(Or maybe the patch proves we're not doing the right thing on the commandline,
either. What do we do for URL->URL copies with parents?)
Received on 2008-12-09 21:45:27 CET