You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Rick Yorgason <ri...@ldagames.com> on 2008/07/08 04:33:25 UTC
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Daniel Shahaf wrote:
> You can test 1.5.x@HEAD to find out. If you find out which revisions (on
> trunk) fixed it, we may be able to backport them.
Tested 1.5.x@HEAD and everything seems to work fine, so it looks like
our woes will be gone in a couple weeks >:)
-Rick-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Fri, 2008-09-12 at 16:31 -0500, David Huang wrote:
> The patch doesn't solve the problem I'm seeing... the commit message for
> r33003 is "Fix "Malformed URL" error on "merge --reintegrate" for a path
> with spaces.", and that does seem to be accurate--it fixes it for "merge
> --reintegrate" only. However, I'm not doing a merge --reintegrate; I'm
> merging a specific revision with merge -c. As Matthew Inger mentioned in
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=142518 ,
> the problem is the way mergeinfo_url is constructed in
> get_mergeinfo_walk_cb. The change he suggested in that email does fix
> the problem for me.
OK. Can you make an actual patch and a log message, please? That would
make it easy for someone to commit it.
For bonus points, it would be great if you could write a regression
test. This would probably be just like the one in r33003... except not
quite just like it.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by David Huang <da...@alterity.com>.
Julian Foad wrote:
> On Tue, 2008-09-09 at 09:08 +0400, Fyodor Sheremetyev wrote:
>
>> I can confirm that the test fails on http without the fix and succeeds
>> with the fix.
>>
>
> Thanks. I have now committed your patch in r33003.
>
The patch doesn't solve the problem I'm seeing... the commit message for
r33003 is "Fix "Malformed URL" error on "merge --reintegrate" for a path
with spaces.", and that does seem to be accurate--it fixes it for "merge
--reintegrate" only. However, I'm not doing a merge --reintegrate; I'm
merging a specific revision with merge -c. As Matthew Inger mentioned in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=142518 ,
the problem is the way mergeinfo_url is constructed in
get_mergeinfo_walk_cb. The change he suggested in that email does fix
the problem for me.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-09-09 at 09:08 +0400, Fyodor Sheremetyev wrote:
> On Tue, Sep 9, 2008 at 1:23 AM, Julian Foad <ju...@btopenworld.com> wrote:
> > 1) Can you (or someone) confirm that the test fails without the fix, and
> > passes with the fix? I can only test on ra-local and ra-svn at the
> > moment, and this new test passed both, even without the fix. I'm not
> > sure if that's expected. I guess it means those protocols don't check
> > for well-formed URLs.
> >
> > If the test and the fix are behaving, we should commit this.
>
> I can confirm that the test fails on http without the fix and succeeds
> with the fix.
Thanks. I have now committed your patch in r33003.
> > 2) Having become aware of this problem, if we look further, there are
> > lots more calls to svn_path_join() that look wrong. Especially, 'grep
> > "url.*svn_path_join"' in Subversion source code reveals a bunch that
> > mostly look wrong. It also reveals a few that use uri_encode() on the
> > second argument that could be replaced by svn_path_url_add_component().
> >
> > Do you fancy (a) fixing those and/or (b) figuring out tests for
> > exercising those?
>
> Yes, I'm going to take deeper and wider look at the encoding/decoding
> problem after this patch is reviewed and committed.
Great.
> > 3) Can we modify our test suite to include paths with spaces in, and
> > thereby catch many URI encoding errors automatically? We can add
> > specific tests for specific cases, but I'm wondering if we can modify
> > the Greek Tree to include some nasty names that will get exercised
> > through several different code paths.
>
> Having all such cases embeded in the whole test suite might make it
> more complex to understand and maintain. I think it's more of a broken
> design than a bug and can be fixed by explicitly setting boundaries
> which would care about URI encoding (and the rest of the code would be
> using decoded URIs).
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Fyodor Sheremetyev <fy...@visualsvn.com>.
On Tue, Sep 9, 2008 at 1:23 AM, Julian Foad <ju...@btopenworld.com> wrote:
> 1) Can you (or someone) confirm that the test fails without the fix, and
> passes with the fix? I can only test on ra-local and ra-svn at the
> moment, and this new test passed both, even without the fix. I'm not
> sure if that's expected. I guess it means those protocols don't check
> for well-formed URLs.
>
> If the test and the fix are behaving, we should commit this.
I can confirm that the test fails on http without the fix and succeeds
with the fix.
> 2) Having become aware of this problem, if we look further, there are
> lots more calls to svn_path_join() that look wrong. Especially, 'grep
> "url.*svn_path_join"' in Subversion source code reveals a bunch that
> mostly look wrong. It also reveals a few that use uri_encode() on the
> second argument that could be replaced by svn_path_url_add_component().
>
> Do you fancy (a) fixing those and/or (b) figuring out tests for
> exercising those?
Yes, I'm going to take deeper and wider look at the encoding/decoding
problem after this patch is reviewed and committed.
> 3) Can we modify our test suite to include paths with spaces in, and
> thereby catch many URI encoding errors automatically? We can add
> specific tests for specific cases, but I'm wondering if we can modify
> the Greek Tree to include some nasty names that will get exercised
> through several different code paths.
Having all such cases embeded in the whole test suite might make it
more complex to understand and maintain. I think it's more of a broken
design than a bug and can be fixed by explicitly setting boundaries
which would care about URI encoding (and the rest of the code would be
using decoded URIs).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Sun, 2008-09-07 at 15:29 +0400, Fyodor Sheremetyev wrote:
> On Tue, Sep 2, 2008 at 11:13 AM, Karl Fogel <kf...@red-bean.com> wrote:
> > "Fyodor Sheremetyev" <fy...@visualsvn.com> writes:
> >> I'm trying to fix this problem. Attached is a short and dirty patch
> >> that makes my reproduction script work. But I'm absolutely unsure that
> >> it fixes the problem correctly.
> >>
> >> I see no consistency in using svn_path_uri_encode and
> >> svn_path_uri_decode in the code and couldn't find any guidelines
> >> regarding uri encoding. Which level should do that by design? Please
> >> could somebody point at the right direction.
> >
> > I think your patch is correct. I've quoted it below so others can see
> > it. A couple of comments:
> >
> > 1. A log message always helps :-). See
> > http://subversion.tigris.org/hacking.html#log-messages
> >
> > 2. You attached it with MIME-type "application/octet-stream", which
> > means that mailreaders can't display it inline. If you use
> > "text/plain" instead, that makes things a bit easier. See
> > http://subversion.tigris.org/hacking.html#patches
> >
> > The guideline for URI encoding and decoding is just to follow the doc
> > strings of whatever functions the data will be passed to. If the
> > function says it needs URI-encoded data, then make sure it receives
> > that. If it does not, then usually it takes un-encoded data.
> >
> > -Karl
>
> Please find attached a bit more polished patch with an appropriate test.
>
> [[[
> Fix "Malformed URL" error on "merge --reintegrate" for a path with spaces.
>
> * subversion/tests/cmdline/merge_tests.py
> (merge_file_with_space_in_its_path): New test.
> (test_list): Run the new test.
>
> * subversion/libsvn_client/merge.c
> (calculate_left_hand_side): URI-encode URLs constructed from URI-decoded
> relative paths.
> ]]]
1) Can you (or someone) confirm that the test fails without the fix, and
passes with the fix? I can only test on ra-local and ra-svn at the
moment, and this new test passed both, even without the fix. I'm not
sure if that's expected. I guess it means those protocols don't check
for well-formed URLs.
If the test and the fix are behaving, we should commit this.
2) Having become aware of this problem, if we look further, there are
lots more calls to svn_path_join() that look wrong. Especially, 'grep
"url.*svn_path_join"' in Subversion source code reveals a bunch that
mostly look wrong. It also reveals a few that use uri_encode() on the
second argument that could be replaced by svn_path_url_add_component().
Do you fancy (a) fixing those and/or (b) figuring out tests for
exercising those?
3) Can we modify our test suite to include paths with spaces in, and
thereby catch many URI encoding errors automatically? We can add
specific tests for specific cases, but I'm wondering if we can modify
the Greek Tree to include some nasty names that will get exercised
through several different code paths.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Fyodor Sheremetyev <fy...@visualsvn.com>.
On Tue, Sep 2, 2008 at 11:13 AM, Karl Fogel <kf...@red-bean.com> wrote:
> "Fyodor Sheremetyev" <fy...@visualsvn.com> writes:
>> I'm trying to fix this problem. Attached is a short and dirty patch
>> that makes my reproduction script work. But I'm absolutely unsure that
>> it fixes the problem correctly.
>>
>> I see no consistency in using svn_path_uri_encode and
>> svn_path_uri_decode in the code and couldn't find any guidelines
>> regarding uri encoding. Which level should do that by design? Please
>> could somebody point at the right direction.
>
> I think your patch is correct. I've quoted it below so others can see
> it. A couple of comments:
>
> 1. A log message always helps :-). See
> http://subversion.tigris.org/hacking.html#log-messages
>
> 2. You attached it with MIME-type "application/octet-stream", which
> means that mailreaders can't display it inline. If you use
> "text/plain" instead, that makes things a bit easier. See
> http://subversion.tigris.org/hacking.html#patches
>
> The guideline for URI encoding and decoding is just to follow the doc
> strings of whatever functions the data will be passed to. If the
> function says it needs URI-encoded data, then make sure it receives
> that. If it does not, then usually it takes un-encoded data.
>
> -Karl
Please find attached a bit more polished patch with an appropriate test.
[[[
Fix "Malformed URL" error on "merge --reintegrate" for a path with spaces.
* subversion/tests/cmdline/merge_tests.py
(merge_file_with_space_in_its_path): New test.
(test_list): Run the new test.
* subversion/libsvn_client/merge.c
(calculate_left_hand_side): URI-encode URLs constructed from URI-decoded
relative paths.
]]]
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Karl Fogel <kf...@red-bean.com>.
"Fyodor Sheremetyev" <fy...@visualsvn.com> writes:
> On Fri, Aug 29, 2008 at 12:44 AM, David Huang <da...@alterity.com> wrote:
>> It looks like Fyodor Sheremetyev was able to create a repro script... here's
>> the call stack:
>
> I'm trying to fix this problem. Attached is a short and dirty patch
> that makes my reproduction script work. But I'm absolutely unsure that
> it fixes the problem correctly.
>
> I see no consistency in using svn_path_uri_encode and
> svn_path_uri_decode in the code and couldn't find any guidelines
> regarding uri encoding. Which level should do that by design? Please
> could somebody point at the right direction.
I think your patch is correct. I've quoted it below so others can see
it. A couple of comments:
1. A log message always helps :-). See
http://subversion.tigris.org/hacking.html#log-messages
2. You attached it with MIME-type "application/octet-stream", which
means that mailreaders can't display it inline. If you use
"text/plain" instead, that makes things a bit easier. See
http://subversion.tigris.org/hacking.html#patches
The guideline for URI encoding and decoding is just to follow the doc
strings of whatever functions the data will be passed to. If the
function says it needs URI-encoded data, then make sure it receives
that. If it does not, then usually it takes un-encoded data.
-Karl
> Index: subversion/libsvn_client/merge.c
> ===================================================================
> --- subversion/libsvn_client/merge.c (revision 32799)
> +++ subversion/libsvn_client/merge.c (working copy)
> @@ -6291,9 +6291,9 @@
> over and over. */
> /* We never merged to the source. Just return the branch point. */
> const char *yc_ancestor_path,
> - *source_url = svn_path_join(source_repos_root, source_repos_rel_path,
> + *source_url = svn_path_join(source_repos_root, svn_path_uri_encode(source_repos_rel_path, subpool),
> subpool),
> - *target_url = svn_path_join(source_repos_root, target_repos_rel_path,
> + *target_url = svn_path_join(source_repos_root, svn_path_uri_encode(target_repos_rel_path, subpool),
> subpool);
>
> SVN_ERR(svn_client__get_youngest_common_ancestor(&yc_ancestor_path,
> @@ -6306,7 +6306,7 @@
> _("'%s@%ld' must be ancestrally related to "
> "'%s@%ld'"), source_url, source_rev,
> target_url, target_rev);
> - *url_left = svn_path_join(source_repos_root, yc_ancestor_path, pool);
> + *url_left = svn_path_join(source_repos_root, svn_path_uri_encode(yc_ancestor_path, pool), pool);
> *source_mergeinfo_p = apr_hash_make(pool);
>
> svn_pool_destroy(subpool);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Fyodor Sheremetyev <fy...@visualsvn.com>.
On Fri, Aug 29, 2008 at 12:44 AM, David Huang <da...@alterity.com> wrote:
> It looks like Fyodor Sheremetyev was able to create a repro script... here's
> the call stack:
I'm trying to fix this problem. Attached is a short and dirty patch
that makes my reproduction script work. But I'm absolutely unsure that
it fixes the problem correctly.
I see no consistency in using svn_path_uri_encode and
svn_path_uri_decode in the code and couldn't find any guidelines
regarding uri encoding. Which level should do that by design? Please
could somebody point at the right direction.
Thanks,
Fyodor
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by David Huang <da...@alterity.com>.
Julian Foad wrote:
>
> If you can't spend much time on it, putting a breakpoint there and
> showing us the call stack might be useful. Otherwise, a reproduction
> script to create a small repository that exhibits the problem would
> definitely be useful, as we could turn that into a regression test.
>
It looks like Fyodor Sheremetyev was able to create a repro script...
here's the call stack:
> svn.exe!parse_url(ne_uri * uri=0x0000000001e4a220, const char *
url=0x0000000002060e40) Line 952 C
svn.exe!svn_ra_neon__reparent(svn_ra_session_t *
session=0x0000000001e23130, const char * url=0x0000000002060e40,
apr_pool_t * pool=0x00000000020374f8) Line 1269 + 0x12 bytes C
svn.exe!svn_ra_reparent(svn_ra_session_t *
session=0x0000000001e23130, const char * url=0x0000000002060e40,
apr_pool_t * pool=0x00000000020374f8) Line 548 C
svn.exe!svn_client__ensure_ra_session_url(const char * *
old_session_url=0x000000000012ecf8, svn_ra_session_t *
ra_session=0x0000000001e23130, const char *
session_url=0x0000000002060e40, apr_pool_t * pool=0x00000000020374f8)
Line 509 + 0x14 bytes C
svn.exe!get_mergeinfo_walk_cb(const char * path=0x0000000002037568,
const svn_wc_entry_t * entry=0x0000000001ee8508, void *
walk_baton=0x000000000012f200, apr_pool_t * pool=0x00000000020374f8)
Line 3398 + 0x29 bytes C
svn.exe!walker_helper(const char * dirpath=0x0000000002037568,
svn_wc_adm_access_t * adm_access=0x0000000001ee83c8, const
svn_wc_entry_callbacks2_t * walk_callbacks=0x0000000140256300, void *
walk_baton=0x000000000012f200, svn_depth_t depth=svn_depth_infinity, int
show_hidden=1, svn_error_t * (void *)* cancel_func=0x000000014000adf0,
void * cancel_baton=0x0000000000000000, apr_pool_t *
pool=0x00000000020374f8) Line 2881 + 0x27 bytes C
svn.exe!walker_helper(const char * dirpath=0x0000000001e51d18,
svn_wc_adm_access_t * adm_access=0x0000000001e17da8, const
svn_wc_entry_callbacks2_t * walk_callbacks=0x0000000140256300, void *
walk_baton=0x000000000012f200, svn_depth_t depth=svn_depth_infinity, int
show_hidden=1, svn_error_t * (void *)* cancel_func=0x000000014000adf0,
void * cancel_baton=0x0000000000000000, apr_pool_t *
pool=0x0000000001e51ca8) Line 2938 + 0x5f bytes C
svn.exe!walker_helper(const char * dirpath=0x0000000001e26a08,
svn_wc_adm_access_t * adm_access=0x0000000001e17910, const
svn_wc_entry_callbacks2_t * walk_callbacks=0x0000000140256300, void *
walk_baton=0x000000000012f200, svn_depth_t depth=svn_depth_infinity, int
show_hidden=1, svn_error_t * (void *)* cancel_func=0x000000014000adf0,
void * cancel_baton=0x0000000000000000, apr_pool_t *
pool=0x0000000001e26998) Line 2938 + 0x5f bytes C
svn.exe!walker_helper(const char * dirpath=0x0000000140320500,
svn_wc_adm_access_t * adm_access=0x0000000001e34af8, const
svn_wc_entry_callbacks2_t * walk_callbacks=0x0000000140256300, void *
walk_baton=0x000000000012f200, svn_depth_t depth=svn_depth_infinity, int
show_hidden=1, svn_error_t * (void *)* cancel_func=0x000000014000adf0,
void * cancel_baton=0x0000000000000000, apr_pool_t *
pool=0x0000000001e228b8) Line 2938 + 0x5f bytes C
svn.exe!svn_wc_walk_entries3(const char * path=0x0000000140320500,
svn_wc_adm_access_t * adm_access=0x0000000001e34af8, const
svn_wc_entry_callbacks2_t * walk_callbacks=0x0000000140256300, void *
walk_baton=0x000000000012f200, svn_depth_t depth=svn_depth_infinity, int
show_hidden=1, svn_error_t * (void *)* cancel_func=0x000000014000adf0,
void * cancel_baton=0x0000000000000000, apr_pool_t *
pool=0x0000000001e228b8) Line 3016 + 0x5c bytes C
svn.exe!get_mergeinfo_paths(apr_array_header_t *
children_with_mergeinfo=0x0000000001e24770, merge_cmd_baton_t *
merge_cmd_baton=0x000000000012f6a0, const char *
merge_src_canon_path=0x0000000001e3dc70, const svn_wc_entry_t *
entry=0x0000000001e34c08, const char *
source_root_url=0x0000000001e3dc08, const char *
url1=0x0000000001e62798, const char * url2=0x0000000001e627f8, long
revision1=21595, long revision2=21596, svn_ra_session_t *
ra_session=0x0000000001e23130, svn_wc_adm_access_t *
adm_access=0x0000000001e34af8, svn_client_ctx_t *
ctx=0x0000000001dfcf40, svn_depth_t depth=svn_depth_infinity, apr_pool_t
* pool=0x0000000001e228b8) Line 3802 + 0x6f bytes C
svn.exe!do_directory_merge(const char * url1=0x0000000001e62798,
long revision1=21595, const char * url2=0x0000000001e627f8, long
revision2=21596, const svn_wc_entry_t * parent_entry=0x0000000001e34c08,
svn_wc_adm_access_t * adm_access=0x0000000001e34af8, svn_depth_t
depth=svn_depth_infinity, notification_receiver_baton_t *
notify_b=0x000000000012f740, merge_cmd_baton_t *
merge_b=0x000000000012f6a0, apr_pool_t * pool=0x0000000001e228b8) Line
4923 + 0xa2 bytes C
svn.exe!do_merge(apr_array_header_t *
merge_sources=0x0000000001e61548, const char *
target=0x0000000140320500, const svn_wc_entry_t *
target_entry=0x0000000001e34c08, svn_wc_adm_access_t *
adm_access=0x0000000001e34af8, int sources_ancestral=1, int
sources_related=1, int same_repos=1, int ignore_ancestry=0, int force=0,
int dry_run=0, int record_only=0, svn_depth_t depth=svn_depth_infinity,
const apr_array_header_t * merge_options=0x0000000000000000,
svn_client_ctx_t * ctx=0x0000000001dfcf40, apr_pool_t *
pool=0x0000000001dfc378) Line 5522 + 0x6d bytes C
svn.exe!svn_client_merge_peg3(const char *
source=0x0000000001e17558, const apr_array_header_t *
ranges_to_merge=0x0000000001dfc598, const svn_opt_revision_t *
peg_revision=0x000000000012f9d8, const char *
target_wcpath=0x0000000140320500, svn_depth_t depth=-2, int
ignore_ancestry=0, int force=0, int record_only=0, int dry_run=0, const
apr_array_header_t * merge_options=0x0000000000000000, svn_client_ctx_t
* ctx=0x0000000001dfcf40, apr_pool_t * pool=0x0000000001dfc378) Line
6468 + 0xcf bytes C
svn.exe!svn_cl__merge(apr_getopt_t * os=0x0000000001dfc5c0, void *
baton=0x000000000012fcd8, apr_pool_t * pool=0x0000000001dfc378) Line
318 + 0x8e bytes C
svn.exe!main(int argc=5, const char * * argv=0x000000000045ad10)
Line 2018 + 0x23 bytes C
svn.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C
svn.exe!mainCRTStartup() Line 403 C
kernel32.dll!0000000077d5964c()
[Frames below may be incorrect and/or missing, no symbols loaded
for kernel32.dll]
It looks like the URL with the spaces is being generated by
get_mergeinfo_walk_cb():
const char *mergeinfo_url =
svn_path_join(wb->source_root_url,
/* Skip leading '/' or join won't work. */
++(merge_src_child_path->data),
pool);
wb->source_root_url = 0x0000000001e3dc08 "https://dev.alterity.com/svn"
merge_src_child_path->data = 0x0000000002060b91
"ACCTivate/Installers/Projects/ACCTivate CIMS Cumulative Update"
Hopefully that gives some hints as to what the problem is :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Fyodor Sheremetyev <fy...@visualsvn.com>.
On Thu, Aug 28, 2008 at 2:27 PM, Julian Foad <ju...@btopenworld.com> wrote:
> Otherwise, a reproduction
> script to create a small repository that exhibits the problem would
> definitely be useful, as we could turn that into a regression test.
Here is a reproduction script for Windows environment. It assumes that
you have an empty repository at https://localhost/svn/repo1/
The script fails with "Malformed URL for repository" error. If you
replace "some folder" with "some-folder" then merge is succesfull.
[[[
set REPO=https://localhost/svn/repo1/
svn co %REPO% wc
mkdir "wc\some folder"
echo one > "wc\some folder\file1.txt"
svn add "wc\some folder"
svn ci wc -m Commit1
svn copy "wc\some folder\file1.txt" "wc\some folder\file2.txt"
svn ci wc -m Commit2
echo two > "wc\some folder\file2.txt"
svn ci wc -m Commit3
svn merge --reintegrate "%REPO%some folder/file2.txt" "wc\some folder\file1.txt"
]]]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Wed, 2008-08-27 at 23:51 -0500, David Huang wrote:
> Hyrum K. Wright wrote:
> > This isn't a solution to the problem, but the 1.5.2 error message for this
> > problem will have additional information which will help the developers fix this
> > issue. Thanks for your patience!
> >
> I applied just that patch (the change to session.c in r32751) to my copy
> of the 1.5.1 source and got:
>
> C:\ACCTivate\64>svn merge -c 21582 https://dev.alterity.com/svn/ACCTivate
>
> svn: URL
> 'https://dev.alterity.com/svn/ACCTivate/Installers/Projects/ACCTivate
> CIMS Cumulative Update' is malformed or the scheme or host or path is
> missing
>
> The problem seems to be the spaces in the path; I'm guessing they should
> be escaped?
Excellent. Now we're getting there.
I'm sorry but I can't dig into this much more right now. David, if you
managed to re-build Subversion from source, it sounds like you are a
person who might be able to help debug this. Would you be willing to
have a go?
If you can't spend much time on it, putting a breakpoint there and
showing us the call stack might be useful. Otherwise, a reproduction
script to create a small repository that exhibits the problem would
definitely be useful, as we could turn that into a regression test.
Thanks,
- Julian
> I recently did an "svn copy" from that URL to the branch
> (https://dev.alterity.com/svn/branches/6.4/Installers/Projects/ACCTivate
> CIMS Cumulative Update), and now that I think about it, this is the
> first time I've tried to merge to branches/6.4 since doing that copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by David Huang <da...@alterity.com>.
Hyrum K. Wright wrote:
> This isn't a solution to the problem, but the 1.5.2 error message for this
> problem will have additional information which will help the developers fix this
> issue. Thanks for your patience!
>
I applied just that patch (the change to session.c in r32751) to my copy
of the 1.5.1 source and got:
C:\ACCTivate\64>svn merge -c 21582 https://dev.alterity.com/svn/ACCTivate
svn: URL
'https://dev.alterity.com/svn/ACCTivate/Installers/Projects/ACCTivate
CIMS Cumulative Update' is malformed or the scheme or host or path is
missing
The problem seems to be the spaces in the path; I'm guessing they should
be escaped?
I recently did an "svn copy" from that URL to the branch
(https://dev.alterity.com/svn/branches/6.4/Installers/Projects/ACCTivate
CIMS Cumulative Update), and now that I think about it, this is the
first time I've tried to merge to branches/6.4 since doing that copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Huang wrote:
> FWIW, I'm having this problem too... server is running Subversion 1.5.1,
> Apache 2.2.9, Windows 2000. Client is Subversion 1.5.1, Windows XP SP3:
>
> C:\ACCTivate\64>svn info
> Path: .
> URL: https://dev.alterity.com/svn/branches/6.4
> Repository Root: https://dev.alterity.com/svn
> Repository UUID: 76cf7a8e-6787-b840-ae13-c52dc3c5383d
> Revision: 21592
> Node Kind: directory
> Schedule: normal
> Last Changed Author: dave
> Last Changed Rev: 21587
> Last Changed Date: 2008-08-25 13:16:44 -0500 (Mon, 25 Aug 2008)
>
>
> C:\ACCTivate\64>svn info https://dev.alterity.com/svn/ACCTivate
> Path: ACCTivate
> URL: https://dev.alterity.com/svn/ACCTivate
> Repository Root: https://dev.alterity.com/svn
> Repository UUID: 76cf7a8e-6787-b840-ae13-c52dc3c5383d
> Revision: 21592
> Node Kind: directory
> Last Changed Author: dave
> Last Changed Rev: 21592
> Last Changed Date: 2008-08-26 16:48:45 -0500 (Tue, 26 Aug 2008)
>
>
> C:\ACCTivate\64>svn merge -c 21582 https://dev.alterity.com/svn/ACCTivate
> svn: Malformed URL for repository
This isn't a solution to the problem, but the 1.5.2 error message for this
problem will have additional information which will help the developers fix this
issue. Thanks for your patience!
-Hyrum
Re: Subversion 1.5 beta1, "malformed URL for repository"
Posted by David Huang <da...@alterity.com>.
FWIW, I'm having this problem too... server is running Subversion 1.5.1,
Apache 2.2.9, Windows 2000. Client is Subversion 1.5.1, Windows XP SP3:
C:\ACCTivate\64>svn info
Path: .
URL: https://dev.alterity.com/svn/branches/6.4
Repository Root: https://dev.alterity.com/svn
Repository UUID: 76cf7a8e-6787-b840-ae13-c52dc3c5383d
Revision: 21592
Node Kind: directory
Schedule: normal
Last Changed Author: dave
Last Changed Rev: 21587
Last Changed Date: 2008-08-25 13:16:44 -0500 (Mon, 25 Aug 2008)
C:\ACCTivate\64>svn info https://dev.alterity.com/svn/ACCTivate
Path: ACCTivate
URL: https://dev.alterity.com/svn/ACCTivate
Repository Root: https://dev.alterity.com/svn
Repository UUID: 76cf7a8e-6787-b840-ae13-c52dc3c5383d
Revision: 21592
Node Kind: directory
Last Changed Author: dave
Last Changed Rev: 21592
Last Changed Date: 2008-08-26 16:48:45 -0500 (Tue, 26 Aug 2008)
C:\ACCTivate\64>svn merge -c 21582 https://dev.alterity.com/svn/ACCTivate
svn: Malformed URL for repository
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Rick Yorgason <ri...@ldagames.com>.
Sorry for the bump, but it's been a week without responses.
Any ideas?
-Rick-
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.
>
> 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.
>
>> 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
>
> And sure enough, that path doesn't exist.
>
> -Rick-
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Rick Yorgason <ri...@ldagames.com>.
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.
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.
> 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
And sure enough, that path doesn't exist.
-Rick-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-07-29 at 10:43 -0400, Rick Yorgason wrote:
> Alright, a couple of interesting things.
>
> First, the reason I missed this before is because it's a heisenbug! It
> only happens in release builds; in debug builds it works perfectly fine.
>
> Second, your patch reveals that something is seriously messed up. Check
> it out:
>
> > C:\Projects\Hegemony.rick>svn merge http://redacted.example.com/svn/Hegemony/trunk//
> > svn: URL 'http://redacted.example.com/svn/Hegmony/Resources Src/Entities/Pedia/pedia_MoraleArrow.png.xnt' is malformed or its scheme or host or path is missing
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?
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?
> >
> > C:\Projects\Hegemony.rick>cd src
> >
> > C:\Projects\Hegemony.rick\src>svn merge http://redacted.example.com/svn/Hegemony/trunk/src/
> > svn: Target path does not exist
Another poor error message. We can't tell what path doesn't exist. Not
necessarily the one you're thinking of.
> First, it chopped out the '/trunk/' part of the remote URL. Then it
> insisted that /trunk/src doesn't exist, even though 'svn info' doesn't
> agree, and then it tried to merge with my coworker's branch!
No, you're making invalid assumptions I think. All of this strange
behaviour probably follows from one bug.
> Any idea what's going on here? Should I dump and reload?
No, I don't think there's anything wrong with your repository data, at
least nothing that a dump and reload would cure.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Rick Yorgason <ri...@ldagames.com>.
Alright, a couple of interesting things.
First, the reason I missed this before is because it's a heisenbug! It
only happens in release builds; in debug builds it works perfectly fine.
Second, your patch reveals that something is seriously messed up. Check
it out:
> C:\Projects\Hegemony.rick>svn merge http://redacted.example.com/svn/Hegemony/trunk//
> svn: URL 'http://redacted.example.com/svn/Hegmony/Resources Src/Entities/Pedia/pedia_MoraleArrow.png.xnt' is malformed or its scheme or host or path is missing
>
> C:\Projects\Hegemony.rick>cd src
>
> C:\Projects\Hegemony.rick\src>svn merge http://redacted.example.com/svn/Hegemony/trunk/src/
> svn: Target path does not exist
>
> C:\Projects\Hegemony.rick\src>svn info
> Path: .
> URL: http://redacted.example.com/svn/Hegemony/branches/rick/src
> Repository Root: http://redacted.example.com/svn
> Repository UUID: dc761664-1389-1943-8935-1db54473a7ad
> Revision: 10614
> Node Kind: directory
> Schedule: normal
> Last Changed Author: rick
> Last Changed Rev: 10572
> Last Changed Date: 2008-07-24 23:59:21 -0400 (Thu, 24 Jul 2008)
>
> C:\Projects\Hegemony.rick\src>svn info http://redacted.example.com/svn/Hegemony/trunk/src
> Path: src
> URL: http://redacted.example.com/svn/Hegemony/trunk/src
> Repository Root: http://redacted.example.com/svn
> Repository UUID: dc761664-1389-1943-8935-1db54473a7ad
> Revision: 10614
> Node Kind: directory
> Last Changed Author: rick
> Last Changed Rev: 10608
> Last Changed Date: 2008-07-29 00:01:42 -0400 (Tue, 29 Jul 2008)
>
> C:\Projects\Hegemony.rick\src>cd "..\Resources Src"
>
> C:\Projects\Hegemony.rick\Resources Src>svn merge "http://redacted.example.com/svn/Hegemony/trunk/Resources Src"
> svn: URL 'http://redacted.example.com/svn/Hegemony/branches/rob/Resources Src/Entities/Pedia/pedia_MoraleArrow.png.xnt' is malformed or its scheme or host or path is missing
First, it chopped out the '/trunk/' part of the remote URL. Then it
insisted that /trunk/src doesn't exist, even though 'svn info' doesn't
agree, and then it tried to merge with my coworker's branch!
Any idea what's going on here? Should I dump and reload?
-Rick-
Julian Foad wrote:
> Did you ever get a chance to try with the more-informative-error-message
> patch:
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Julian Foad <ju...@btopenworld.com>.
On Tue, 2008-07-29 at 05:02 -0400, Rick Yorgason wrote:
> Alright, well, 1.5.1 is out. You guys don't have binaries up yet, but
> Tortoise does, and this problem has returned >_<
>
> Back to the drawing board...
Did you ever get a chance to try with the more-informative-error-message
patch:
> Index: subversion/libsvn_ra_neon/session.c
> ===================================================================
> --- subversion/libsvn_ra_neon/session.c (revision 31858)
> +++ subversion/libsvn_ra_neon/session.c (working copy)
> @@ -947,8 +947,9 @@
> || uri->host == NULL || uri->path == NULL || uri->scheme ==
> NULL)
> {
> ne_uri_free(uri);
> - return svn_error_create(SVN_ERR_RA_ILLEGAL_URL, NULL,
> - _("Malformed URL for repository"));
> + return svn_error_createf(SVN_ERR_RA_ILLEGAL_URL, NULL,
> + _("URL '%s' is malformed or its "
> + "scheme or host or path is
> missing"), url);
> }
> if (uri->port == 0)
> uri->port = ne_uri_defaultport(uri->scheme);
? Or just set a breakpoint at that place if that's easier for you.
Unfortunately this tweak isn't in 1.5.1.
- Julian
> > Rick Yorgason wrote on Tue, 8 Jul 2008 at 00:33 -0400:
> >> Tested 1.5.x@HEAD and everything seems to work fine, so it looks like our woes
> >> will be gone in a couple weeks >:)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Rick Yorgason <ri...@ldagames.com>.
Alright, well, 1.5.1 is out. You guys don't have binaries up yet, but
Tortoise does, and this problem has returned >_<
Back to the drawing board...
-Rick-
Daniel Shahaf wrote:
> Rick Yorgason wrote on Tue, 8 Jul 2008 at 00:33 -0400:
>> Daniel Shahaf wrote:
>>> You can test 1.5.x@HEAD to find out. If you find out which revisions (on
>>> trunk) fixed it, we may be able to backport them.
>> Tested 1.5.x@HEAD and everything seems to work fine, so it looks like our woes
>> will be gone in a couple weeks >:)
>>
>
> You can thank hwright for that. (I think he plans 1.5.1 by the end of the
> month.) Thanks for confirming the fix.
>
> Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS: Subversion 1.5 beta1, "malformed URL for repository"
Posted by Daniel Shahaf <d....@daniel.shahaf.co.il>.
Rick Yorgason wrote on Tue, 8 Jul 2008 at 00:33 -0400:
> Daniel Shahaf wrote:
> > You can test 1.5.x@HEAD to find out. If you find out which revisions (on
> > trunk) fixed it, we may be able to backport them.
>
> Tested 1.5.x@HEAD and everything seems to work fine, so it looks like our woes
> will be gone in a couple weeks >:)
>
You can thank hwright for that. (I think he plans 1.5.1 by the end of the
month.) Thanks for confirming the fix.
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org