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

Re: VS: Subversion 1.5 beta1, "malformed URL for repository"

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 05 Aug 2008 22:04:42 +0100

Rick,

Thanks for your prod. Sorry, I don't have any more insight nor the
ability to reproduce this. All I can offer is a few probing questions...

On Tue, 2008-07-29 at 12:16 -0400, Rick Yorgason wrote:
> Julian Foad wrote:
> > OK, there is one question here and one bug.
> >
> > Q: Why is Subversion looking at the path ".../Resources Src/..."?
> > A: Maybe because it's in the mergeinfo.
> > Q: Is that path in your svn:mergeinfo property on the trunk?
>
> There is no svn:mergeinfo property in *any* of the folders in question,
> or, for that matter, anywhere in the entire repository.

Do you mean "anywhere in the head revision in the repository"? You can't
(without being an admin on the server side) remove the svn:mergeinfo
from revisions that are already in the repository.

> I *did* have svn:mergeinfo in my branch (/branches/rick) during the
> 1.5.0 beta, way back before this problem started, and when you used to
> be able to do merge tracking without upgrading your server, but since
> then I deleted it.

> /branches/rick has also been deleted and replaced with a fresh copy of
> the trunk since then. Actually, it was deleted and replaced *today*,
> right after I upgraded to 1.5.1.
>
> I noticed that there wasn't any mergeinfo in /branches/rick after doing
> that, but I wasn't sure if there was supposed to be.

I believe the mergeinfo on the destination of a copy should be identical
to how it was on the source. If there was none on the trunk, there would
be none on the newly created branch.

> > Bug: That string is not a valid URL because it had a space in it.
> > Q: How did it fail to be properly escaped (as "%20")?
> > A: Maybe a bug in the mergeinfo generation.
> > Q: Can you show us the mergeinfo?
>
> No svn:mergeinfo props. If there's anything else you'd like to know,
> I'd be happy to oblige.
>
> > Another poor error message. We can't tell what path doesn't exist. Not
> > necessarily the one you're thinking of.
>
> You have a point. The message is on the server-end, and I'm not so keep
> on running experimental builds on our server, so I used Wireshark to see
> what path my client was sending to the server. Sure enough, this is
> what the dest-path tag read:
>
> http://redacted.example.com/svn/Hegemony/src

The client sent that as a "dest-path" of what, when? It might be
informative to show us a more complete transcript of a client-side
command plus the actual network trace resulting from it. You can
continue to replace some sensitive parts (like the server name) with
dummy data.

> And sure enough, that path doesn't exist.

What happens at the same point in the network trace if you use the same
client-side command except adding a user name into the URL in the way
you showed us earlier in this thread
("http://@redacted.example.com/..."), to make the command succeed?

Or rather, where is the first point that the two network traces start to
differ significantly depending on whether there is a user name field?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-05 23:05:10 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.