You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mikhail Terekhov <te...@emc.com> on 2006/10/20 22:03:10 UTC
svnsync failure
Hi,
I'm using svnsync to mirror our repository and all was fine, but
recently svnsync started to fail with the following message
svnsync: REPORT request failed on 'https://svn.myserver.com/myproject'
svnsync: REPORT of 'https://svn.myserver.com/myproject': 200 OK
(https://svn.myserver.com)
There was no any config changes as far as I can see. Server is a Sun
machine and the client is a Linux box. Both have 1.4.0 (r21228) installed.
Any ideas what could be the reason?
Thank you
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnsync failure
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com> wrote:
> Thank you, that was quick!
Once I knew about the spaces in the filenames the problem was pretty
easy to track down. None of the repositories I tested on up to now
had a character that needed to be uri encoded in a source of a copy
operation, so the bug slipped through the cracks.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svnsync failure
Posted by Te...@emc.com.
> -----Original Message-----
> From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of Garrett
> Rooney
> Sent: Monday, October 23, 2006 5:11 PM
> To: Terekhov, Mikhail
> Cc: terekhov@emc.com; users@subversion.tigris.org
> Subject: Re: svnsync failure
>
> On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com>
wrote:
> >
> >
> > > -----Original Message-----
> > > From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of
Garrett
> > > Rooney
> > > Sent: Monday, October 23, 2006 4:08 PM
> > > To: Terekhov, Mikhail
> > > Cc: terekhov@emc.com; users@subversion.tigris.org
> > > Subject: Re: svnsync failure
> > >
> > > On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com>
> > wrote:
> > >
> > > > The repository is small, so it is relatively easy to experiment.
> > I've
> > > > dumped offending revision (359), loaded it into destination
> > repository
> > > > and svnsync became happy again.
> > > >
> > > > The revision in question is very simple - it is just a one file
> > rename.
> > > > User (on Windows box & svn-1.3.2) renamed file with a space in
the
> > name:
> > > > "some%20name.ext" --> "some name.ext".
> > >
> > > Interesting. Maybe there's a url encoding problem in the svnsync
code
> > > someplace.
> > >
> > > > It is strange but 'svn log --verbose -r 359' says nothing, just
a
> > single
> > > > line of dashes (both 1.4.0 and trunk versions).
> > >
> > > That's likely an issue of where you run the log from. If you give
it
> > > a target of the root of the repos (i.e.
> > > https://svn.myserver.com/myproject) you should see something.
> > >
> > > > Svncync from the trunk gives the following error:
> > > >
> > > > svnsync: REPORT request failed on
> > 'https://svn.myserver.com/myproject'
> > > > svnsync: File not found: revision 358, path '/my/path/some
name.ext'
> > > >
> > > > Why 358? The file was created in rev. 230 and never changed
since.
> > >
> > > Not sure, if I knew that I'd probably have fixed the bug already
;-)
> > >
> > > If you could try using the repos URL as the target of the log that
> > > would be helpful, once I have that I should be able to dumplicate
the
> > > problem and fix it.
> > >
> >
> > svn log --verbose -r 359 https://svn.myserver.com/myproject
> >
> > gives:
> >
> >
------------------------------------------------------------------------
> > r359 | username | 2006-10-20 16:25:25 -0400 (Fri, 20 Oct 2006) | 1
line
> > Changed paths:
> > A /docs/subdir/some name.ext (from
/docs/subdir/some%20name.ext:358)
> > D /docs/subdir/some%20name.ext
> >
> > Renamed remotely
> >
------------------------------------------------------------------------
>
> Thanks! This is fixed on trunk in r22092, I'll propose it for
> backport to 1.4.x as soon as I confirm that it builds there.
>
Thank you, that was quick!
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnsync failure
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com> wrote:
>
>
> > -----Original Message-----
> > From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of Garrett
> > Rooney
> > Sent: Monday, October 23, 2006 4:08 PM
> > To: Terekhov, Mikhail
> > Cc: terekhov@emc.com; users@subversion.tigris.org
> > Subject: Re: svnsync failure
> >
> > On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com>
> wrote:
> >
> > > The repository is small, so it is relatively easy to experiment.
> I've
> > > dumped offending revision (359), loaded it into destination
> repository
> > > and svnsync became happy again.
> > >
> > > The revision in question is very simple - it is just a one file
> rename.
> > > User (on Windows box & svn-1.3.2) renamed file with a space in the
> name:
> > > "some%20name.ext" --> "some name.ext".
> >
> > Interesting. Maybe there's a url encoding problem in the svnsync code
> > someplace.
> >
> > > It is strange but 'svn log --verbose -r 359' says nothing, just a
> single
> > > line of dashes (both 1.4.0 and trunk versions).
> >
> > That's likely an issue of where you run the log from. If you give it
> > a target of the root of the repos (i.e.
> > https://svn.myserver.com/myproject) you should see something.
> >
> > > Svncync from the trunk gives the following error:
> > >
> > > svnsync: REPORT request failed on
> 'https://svn.myserver.com/myproject'
> > > svnsync: File not found: revision 358, path '/my/path/some name.ext'
> > >
> > > Why 358? The file was created in rev. 230 and never changed since.
> >
> > Not sure, if I knew that I'd probably have fixed the bug already ;-)
> >
> > If you could try using the repos URL as the target of the log that
> > would be helpful, once I have that I should be able to dumplicate the
> > problem and fix it.
> >
>
> svn log --verbose -r 359 https://svn.myserver.com/myproject
>
> gives:
>
> ------------------------------------------------------------------------
> r359 | username | 2006-10-20 16:25:25 -0400 (Fri, 20 Oct 2006) | 1 line
> Changed paths:
> A /docs/subdir/some name.ext (from /docs/subdir/some%20name.ext:358)
> D /docs/subdir/some%20name.ext
>
> Renamed remotely
> ------------------------------------------------------------------------
Thanks! This is fixed on trunk in r22092, I'll propose it for
backport to 1.4.x as soon as I confirm that it builds there.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svnsync failure
Posted by Te...@emc.com.
> -----Original Message-----
> From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of Garrett
> Rooney
> Sent: Monday, October 23, 2006 4:08 PM
> To: Terekhov, Mikhail
> Cc: terekhov@emc.com; users@subversion.tigris.org
> Subject: Re: svnsync failure
>
> On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com>
wrote:
>
> > The repository is small, so it is relatively easy to experiment.
I've
> > dumped offending revision (359), loaded it into destination
repository
> > and svnsync became happy again.
> >
> > The revision in question is very simple - it is just a one file
rename.
> > User (on Windows box & svn-1.3.2) renamed file with a space in the
name:
> > "some%20name.ext" --> "some name.ext".
>
> Interesting. Maybe there's a url encoding problem in the svnsync code
> someplace.
>
> > It is strange but 'svn log --verbose -r 359' says nothing, just a
single
> > line of dashes (both 1.4.0 and trunk versions).
>
> That's likely an issue of where you run the log from. If you give it
> a target of the root of the repos (i.e.
> https://svn.myserver.com/myproject) you should see something.
>
> > Svncync from the trunk gives the following error:
> >
> > svnsync: REPORT request failed on
'https://svn.myserver.com/myproject'
> > svnsync: File not found: revision 358, path '/my/path/some name.ext'
> >
> > Why 358? The file was created in rev. 230 and never changed since.
>
> Not sure, if I knew that I'd probably have fixed the bug already ;-)
>
> If you could try using the repos URL as the target of the log that
> would be helpful, once I have that I should be able to dumplicate the
> problem and fix it.
>
svn log --verbose -r 359 https://svn.myserver.com/myproject
gives:
------------------------------------------------------------------------
r359 | username | 2006-10-20 16:25:25 -0400 (Fri, 20 Oct 2006) | 1 line
Changed paths:
A /docs/subdir/some name.ext (from /docs/subdir/some%20name.ext:358)
D /docs/subdir/some%20name.ext
Renamed remotely
------------------------------------------------------------------------
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnsync failure
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/23/06, Terekhov_mikhail@emc.com <Te...@emc.com> wrote:
> The repository is small, so it is relatively easy to experiment. I've
> dumped offending revision (359), loaded it into destination repository
> and svnsync became happy again.
>
> The revision in question is very simple - it is just a one file rename.
> User (on Windows box & svn-1.3.2) renamed file with a space in the name:
> "some%20name.ext" --> "some name.ext".
Interesting. Maybe there's a url encoding problem in the svnsync code
someplace.
> It is strange but 'svn log --verbose -r 359' says nothing, just a single
> line of dashes (both 1.4.0 and trunk versions).
That's likely an issue of where you run the log from. If you give it
a target of the root of the repos (i.e.
https://svn.myserver.com/myproject) you should see something.
> Svncync from the trunk gives the following error:
>
> svnsync: REPORT request failed on 'https://svn.myserver.com/myproject'
> svnsync: File not found: revision 358, path '/my/path/some name.ext'
>
> Why 358? The file was created in rev. 230 and never changed since.
Not sure, if I knew that I'd probably have fixed the bug already ;-)
If you could try using the repos URL as the target of the log that
would be helpful, once I have that I should be able to dumplicate the
problem and fix it.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: svnsync failure
Posted by Te...@emc.com.
> -----Original Message-----
> From: rooneg@gmail.com [mailto:rooneg@gmail.com] On Behalf Of Garrett
> Rooney
> Sent: Monday, October 23, 2006 1:43 PM
> To: Mikhail Terekhov
> Cc: users@subversion.tigris.org
> Subject: Re: svnsync failure
>
> On 10/20/06, Mikhail Terekhov <te...@emc.com> wrote:
> > Hi,
> >
> > I'm using svnsync to mirror our repository and all was fine, but
> > recently svnsync started to fail with the following message
> >
> > svnsync: REPORT request failed on
'https://svn.myserver.com/myproject'
> > svnsync: REPORT of 'https://svn.myserver.com/myproject': 200 OK
> > (https://svn.myserver.com)
> >
> > There was no any config changes as far as I can see. Server is a Sun
> > machine and the client is a Linux box. Both have 1.4.0 (r21228)
> installed.
> >
> > Any ideas what could be the reason?
>
> Interesting. Is there anything odd about the revision it's trying to
> mirror when it hits that error? A 'svn log --verbose -r X' where X ==
> that revision would be interesting. Alternatively, it might be useful
> to see a neon debug trace from that operation. As a final resort, in
> the current trunk version of subversion the error message you'll get
> from that sort of situation will be far more useful (i.e. no "200 OK"
> crap), so you could rebuild with trunk and try it again and see if
> that gives you something more meaningful.
>
The repository is small, so it is relatively easy to experiment. I've
dumped offending revision (359), loaded it into destination repository
and svnsync became happy again.
The revision in question is very simple - it is just a one file rename.
User (on Windows box & svn-1.3.2) renamed file with a space in the name:
"some%20name.ext" --> "some name.ext".
It is strange but 'svn log --verbose -r 359' says nothing, just a single
line of dashes (both 1.4.0 and trunk versions).
Svncync from the trunk gives the following error:
svnsync: REPORT request failed on 'https://svn.myserver.com/myproject'
svnsync: File not found: revision 358, path '/my/path/some name.ext'
Why 358? The file was created in rev. 230 and never changed since.
Regards,
Mikhail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: svnsync failure
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/20/06, Mikhail Terekhov <te...@emc.com> wrote:
> Hi,
>
> I'm using svnsync to mirror our repository and all was fine, but
> recently svnsync started to fail with the following message
>
> svnsync: REPORT request failed on 'https://svn.myserver.com/myproject'
> svnsync: REPORT of 'https://svn.myserver.com/myproject': 200 OK
> (https://svn.myserver.com)
>
> There was no any config changes as far as I can see. Server is a Sun
> machine and the client is a Linux box. Both have 1.4.0 (r21228) installed.
>
> Any ideas what could be the reason?
Interesting. Is there anything odd about the revision it's trying to
mirror when it hits that error? A 'svn log --verbose -r X' where X ==
that revision would be interesting. Alternatively, it might be useful
to see a neon debug trace from that operation. As a final resort, in
the current trunk version of subversion the error message you'll get
from that sort of situation will be far more useful (i.e. no "200 OK"
crap), so you could rebuild with trunk and try it again and see if
that gives you something more meaningful.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org