Addition to the previous post.

Now I gave a range for merging and I got this message. "Malformed URL
for repository"

What I did is that I selected merge > merge a range of revisions >
selected URL to merge from by selecting from repository browser by
clicking button besides the input box. And I gave the revision range
by looking up the logs (I hate this). Then clicked the 'test merge'
button. On the popup window which shows the result of merging showed
the error message.

What's wrong with this? I am sure that the URL is correct!!!

Thanks.

- Derrick

Any luck with this? We are experiencing the same issue :(

On Jul 15, 8:57 am, Derrick <derrickmeis...@gmail.com> wrote:

Similar issue is discussed here:
http://www.nabble.com/Re%3A-Subversion-1.5-beta1%2C-%22malformed-URL-...

Please try adding "@" sign before server name and let us know if that helps.

Fyodor Sheremetyev
VisualSVN Team

We added an @ and we got a different error.

Without the @ the error is: "Malformed URL for repository"

With the @ the error is: "Error: URL
Error: 'https:/...@xxxxxxxxx.xxxxxxx.xxxxxx.xxx/svn/xxx/xx/Branches/
Source/xxxxxxxxxxxxxxxxxxxxxxxxxxx/xxxx.x%20xxxxxxxxx%20xxxx
%20xxxxxxxxx%20xxxx'
Error: is not a child of repository root URL 'https://
xxxxxxxxx.xxxxxxx.xxxxxx.xxx/svn/xxx'

On Jul 21, 5:48 pm, "VisualSVN Team" <supp...@visualsvn.com> wrote:

I was getting the same error and this worked perfectly. Thanks!

VisualSVN team,

Is this an issue with the server? client? is it being worked on?
Though the @ workaround works, it looses track of version that have
been merged...

I know it probably is problem with core SVN, I just want to check what
the root cause is.

Eric.

On Jul 23, 9:32 am, czwi...@gmail.com wrote:

I had the same problem, and just discovered that if I use http://
instead of https:// in my repository url, it works fine. I think the
problem has to do with svn merge and https.

We're experiencing the exact same issue, and we only use the http
protocol (as opposed to https). We're using TortoiseSVN 1.5.2, Build
13595 and VisualSVN server 1.5.2.

I haven't found much out there to suggest it's a problem with our
client or Subversion itself, so I'm curious myself if it's an
acknowledged issue with VisualSVN. Using the '@' fix mentioned above
allows us to work around the issue, but it completely breaks merge
tracking. In fact, when I go to branch from the trunk, the
svn:mergeinfo property isn't set at all on the new branch and any
merges from that point on have to include the '@' fix or else the
"Malformed URL for repository" error is given.

Is this something that the Visual SVN team is aware of? Either way, is
anyone aware of any workarounds so that we can use merge tracking? I
can provide more details and the exact replication steps if desired.

Please provide reproduction script.

Thanks,
Fyodor Sheremetyev
VisualSVN Team

My merge is also broken..  both on Command line.. and using
TortoiseSVN...

This is a major issue for us and is causing great grief in the
company...  What is the status of an emergency patch to fix this
issue??

On Aug 23, 1:20 am, "VisualSVN Team" <supp...@visualsvn.com> wrote:

Hi Darren,

We cannot reproduce the problem. Please provide steps to reproduce it
- then we will be able to investigate it.

Thanks,
Fyodor Sheremetyev
VisualSVN Team

Note to all:
As much as I appreciate the VisualSVN company for its VS plug-in, I
think this thread is a perfect reminder that when it comes to server,
you are better off with the original, even if you want to pay
CollabNet.

"please provide a reproduction script": NO. I am a customer. Not one
of the developers. My role is to use the product. Not help you build
it. Will I get a free copy for my entire company when you decide to
start charging for it?

This is obviously a widespread issue that will require some
investigative work on your part. Have you tried running on various
versions of Windows Server? In our case, we had no problem when
running in our pilot environment (XP workstation) but since we rolled
out to prod, under Windows Server 2003 with a full server, we are
getting Malformed URL issues all over the place along with 500 errors.
We are at the point where we probably will have to turn to the
CollabNet product and definitely make sure we stick to the VS plug-in
only with VisualSVN, especially if you make it a commercial product.

Regards,

Eric.

On Aug 27, 9:44 am, "VisualSVN Team" <supp...@visualsvn.com> wrote:

Hi Darren,

Thanks a lot for the additional information!

I was able to reproduce the problem. It seems to be caused by space
character in the folder name ("SearchPrior Webservice"). Will
investigate further now.

Do all who experience the "Malformed URL" error have or had a folder
with space character in the name?

Fyodor Sheremetyev
VisualSVN Team

It doesn’t matter if there is a space or not... Even paths w/o any spaces give the same problem

Darren McDaniel

Software Developer
Production Support
803-941-1900 x2180
888-333-5696 x2180
Direct Fax: 803-941-0517
dmcdan...@geninfo.com

And just exactly how do you expect them to fix the problem when they
can't recreate it, and you won't provide them with the steps that *will*
recreate it?

Brad,
if you asked your customers to tell you exactly how they broke your
product(s) and tell them you won't fix it until they give you exactly
the steps they took to break it (no matter how many there could be),
would you still be in business?.
Part of being a good software company is the ability to extrapolate
root causes based on limited information. For example: "when I click
the button nothing happens" => Is the click event designed correctly?
does the action depend on external factors? etc.
If VisualSVN's answer to advanced issues is "tell us exactly what is
wrong and we will go and modify the line of code you identified is
wrong", I think people have the right be alarmed if they decide to
charge for VisualSVN Server.
If VisualSVN is apparently hinting that it is related to spaces in
file names and they have never encountered that issue on their own,
this leads me to believe that they are not testing for a lot of common
cases.
Again, since it's free, and Subversion is open source, yes, I could
get my hands dirty, tell my boss that this week, instead of working
for him, I'll be debugging Subversion/Apache/etc., but Subversion is
"advertised" as an enterprise-ready solution, on which VisualSVN is
basing its business.
In this thread, it's apparent that there IS an issue. It's impacting
enough customers that some are spending time on-line writing about it.
How many users do you think have the problem but either decided that
the workaround is enough or that since there is no progress and they
don't know much more about what could be the root cause, have decided
to not post?

I have been a Subversion user pretty much since 1.0. I love it. I am
so convinced of its greatness that I jumped at the opportunity to head
the migration from SourceSafe at my new employer's. The availability
of the VisualSVN plug-in has definitely been a positive and has help
establish Subversion within our company. But we are now plagued with
"500" errors and "Malformed URLs" errors and the time we are spending
investigating root causes, workarounds, status and maybe alternative
Subversion Server options is costing us money.

I look forward to the VisualSVN team coming up with a solution to this
issue.

Regards,

Eric.

On Aug 28, 9:59 am, "Brad Stiles" <bradley.sti...@gmail.com> wrote:

I do exactly that, and I am, thank you.

And from what I saw, they attempted to do exactly that and failed, thus
the request for more information.

Nothing in the message I saw demanded that you identify the "line of
code" that is wrong.  They asked for a reproduction recipe, a standard
practice in software development, both shrink-wrapped and open source
varieties.  Heck, I asked for that type of thing when I was working on
*mainframes*.  Given the wide variety of possible hardware and softward
configurations on Windows machines these days, it's essential to know
how to reproduce a problem, and your blustering refusal to provide that
information, while indicative of your perhaps justified level of
frustration, does nothing to help solve the actual problem.

"Doctor, I'm sick, what's wrong?"
"Tell me your symptoms."
"NO.  I'm the patient, you're the doctor, you figure it out."

I had this exact same problem.  The URL has spaces in.  I renamed the
directories with spaces, replacing the " " with "_", and it worked
fine.

Hope that this helps identify the issue.

Jonathan

this 'fix' does not work... no matter if I have a simple url with no
spaces.. or substitute a %20 for any existing space.. I get the same
error...

this is a bug in the merge routine.. and I am hoping that the team at
VisualSVN / Subversion can work this out...

On Sep 3, 7:06 am, "ac931...@googlemail.com" <ac931...@googlemail.com>
wrote:

We are working on a fix for the case with spaces.

If you could provide a reproduction script or more details on your
case it would be of great help.

Thanks,
Fyodor

Hi Fyodor

I am using the serverside component of VisualSVN and I too have
encountered this error.

I performed a merge from my BasePoint (Copy of Original Trunk) to a
MergePoint00 (Copy of Current Trunk) and applied the diff to a working
copy of a branch where I was developing a feature. (Methodology
courtesy of Travis Illig)

On those occasions when this goes wrong....
- I try a test merge
- The test merge works flawlessly.
- I try a real Merge
- The Status message is ....
-------------------------------------------------------------
Merging from http://balrog:3690/PDB/branches/BP/Features/FB976/Merge/FromTrunk/Bas...,
revision HEAD to http://balrog:3690/PDB/branches/BP/Features/FB976/Merge/FromTrunk/Mer...,
revision HEAD into D:\Development\FB976, respecting ancestry
-------------------------------------------------------------
- All files appear to merge correctly in the status window being
indicated by an "updated" message.
- The Status window has 1 additional message "Malformed URL for
repository".
- The Status window declares that it is finished.

At this point I am reasonably convinced that things have actually
worked and that the message is spurious.

All files seem to have the correct content and all seems well apart
from this message.

If I elect to commit these from my working copy back to my dev branch,
then the correct number of files are affected and they are affected
correctly.
The commit yields no error messages and appears to work.

My urls are internal to my company intranet and cannot be accessed
from outside.
They do not contain a space character.
I am unsure what you mean by a reproduction script. Perhaps this email
will serve.

I can tell you that

svn merge -r "7871:HEAD" "http://hostname/svn/repos/MyProject/branches/
dev@HEAD" "C:\MyProject\Trunk"

causes the Malformed URL error, but

svn merge -r "7871:HEAD" "http://userid@hostname/svn/repos/MyProject/
branches/dev@HEAD" "C:\MyProject\Trunk"

does not, which is simply how you supply the user ID in the URL.

Others have suggested that just putting the '@' in there, presumably
without an ID, does the trick.  It is possible that it stores the user
ID as blank (as opposed to null when '@' is not supplied).  It is also
possible that the parser simply identifies the host correctly.  Either
way, there appears to be URL validation involving the host and
possibly user id fields that is failing during the merge process.

I'd also like to add that the exact merge has worked successfully in
the past.  Without changing the merge syntax that I had in an Ant
script, the issue suddenly began today.  I don't remember if I
upgraded SVN on the client or server since then, but certainly don't
remember.

I did refactor the project a lot, though.  The core folders in the
project were moved and renamed.  Since HTTP clients use URLs to access
all this info, it could have errored when comparing the source branch
to the dramatically different destination branch.  This is the only
significant difference I can think of since I last merged about a week
or so ago.