RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

2013-08-18 Thread Geoff Field

From: Nico Kadel-Garcia
Sent: Friday, 16 August 2013 21:39 PM
To: Geoff Field
Cc: Philip Martin; users@subversion.apache.org
Subject: Re: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

Get your legacy material off BDB and onto FSFS, ASAP. At least make sure you 
have *good* backups and are prepared to lose all that data if you don't. BDB 
has been, in my experience with much older versions of Subversion and with 
years of Linux application experience, prone to data corruption from 
unpredictable and unrecoverable userland events and even the slightest blip of 
the OS or hardware layer. It has also repeatedly proven impossible to upgrade 
existing data sets to new BDB releases in place. Subversion fortunately has a 
workable backup system to provide data transfers: I've seen BDB systems that 
did not.
Thanks for the opinion Nico.  I'm in the middle of doing the translation now.  
As I said, though, we have about 100 repositories, most of them in BDB format, 
so it's no small task.

The servers are backed up nightly using IBM's Tivoli Storage Manager.  I've had 
to recover repositories a few times using that tool, so I know it works for us.

BDB has never been my friend.

We've had a few corrupt repositories over the years.  We got to the stage where 
we wrote an internal Wiki page on fixing corrupt repositories.

We had a colleague write an application to help with management of the repos.  
Unfortunately, he chose to create them in BDB format.  That's  why we have so 
many BDB repositories.  Rather than recreate the build environment and rebuild 
the management application, I've edited the EXE file to replace the (DBCS) 
string that sets the format with spaces.

 Geoff
On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field wrote:
> From: Geoff Field
> Sent: Friday, 16 August 2013 11:56 AM
> Thanks to everybody for their patience with my issue.  The
> root cause is not really solved, but at least I (and my
> colleagues) can get back to normal work patterns.
>
> I've finally managed to get the upgrade to Apache 2.2 and SVN
> server 1.6.9 running.  As it turns out, my former colleagues
> had deliberately configured all the ports one up from the
> default (thus, SSL was running on port 444 instead of the
> default 443).  Once I'd fixed this, Apache 2.2 started
> serving SVN via the default interfaces.
>
> With that, I can now run everything happily.

It seems I spoke too soon.  It turns out that the updated SVN server 1.6.9 
works for those few of our repositories that are in FSFS format.  
Unfortunately, our legacy repositories are almost all in BDB format and I'm 
loathe to touch them if I can avoid it.

Building SVN from source is not really a useful option, but we can do it (with 
a struggle) if we absolutely have to.   Frankly, I'd rather convert all the 
repositories (and there are 100 all up, although some are in FSFS format 
already) than build the server code.  Has anybody built a version that handles 
BDB in a DAV module?

> I have not deleted the Apache 2.0/SVN server 1.2.3
> configuration, so I should be able to switch back to that if
> needed.  I suppose it's possible some repositories might
> become inaccessible to the earlier server due to the server
> upgrade, but I'm not particularly fussed about that.

We can swap back to the other version fairly easily if we have to, just by 
stopping Apache2.2 and starting Apache2 (or vice-versa).

Regards,

Geoff

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




Re: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

2013-08-16 Thread Nico Kadel-Garcia
Get your legacy material off BDB and onto FSFS, ASAP. At least make sure
you have *good* backups and are prepared to lose all that data if you
don't. BDB has been, in my experience with much older versions of
Subversion and with years of Linux application experience, prone to data
corruption from unpredictable and unrecoverable userland events and even
the slightest blip of the OS or hardware layer. It has also repeatedly
proven impossible to upgrade existing data sets to new BDB releases in
place. Subversion fortunately has a workable backup system to provide data
transfers: I've seen BDB systems that did not.

BDB has never been my friend.


On Fri, Aug 16, 2013 at 2:13 AM, Geoff Field wrote:

> > From: Geoff Field
> > Sent: Friday, 16 August 2013 11:56 AM
> > Thanks to everybody for their patience with my issue.  The
> > root cause is not really solved, but at least I (and my
> > colleagues) can get back to normal work patterns.
> >
> > I've finally managed to get the upgrade to Apache 2.2 and SVN
> > server 1.6.9 running.  As it turns out, my former colleagues
> > had deliberately configured all the ports one up from the
> > default (thus, SSL was running on port 444 instead of the
> > default 443).  Once I'd fixed this, Apache 2.2 started
> > serving SVN via the default interfaces.
> >
> > With that, I can now run everything happily.
>
> It seems I spoke too soon.  It turns out that the updated SVN server 1.6.9
> works for those few of our repositories that are in FSFS format.
>  Unfortunately, our legacy repositories are almost all in BDB format and
> I'm loathe to touch them if I can avoid it.
>
> Building SVN from source is not really a useful option, but we can do it
> (with a struggle) if we absolutely have to.   Frankly, I'd rather convert
> all the repositories (and there are 100 all up, although some are in FSFS
> format already) than build the server code.  Has anybody built a version
> that handles BDB in a DAV module?
>
> > I have not deleted the Apache 2.0/SVN server 1.2.3
> > configuration, so I should be able to switch back to that if
> > needed.  I suppose it's possible some repositories might
> > become inaccessible to the earlier server due to the server
> > upgrade, but I'm not particularly fussed about that.
>
> We can swap back to the other version fairly easily if we have to, just by
> stopping Apache2.2 and starting Apache2 (or vice-versa).
>
> Regards,
>
> Geoff
>
> --
> Geoff Field
> Testing Coordinator, Work Health & Safety Rep, Chief Fire Warden, First
> Aider
> Australian Arrow Pty Ltd www.australianarrow.com.au
> 46 Lathams Rd, Carrum Downs, Vic, 3201, Australia
> phone (+61-3) 97850597, fax (+61-3) 9785 0583
> GYNET x-067-597
> - The contents of this email, and any attachments, are strictly private
> and confidential.
> - It may contain legally privileged or sensitive information and is
> intended
> solely for the individual or entity to which it is addressed.
> - Only the intended recipient may review, reproduce, retransmit, disclose,
> disseminate or otherwise use or take action in reliance upon the
> information
> contained in this email and any attachments, with the permission of
> Australian Arrow Pty. Ltd.
> - If you have received this communication in error, please reply to the
> sender
> immediately and promptly delete the email and attachments, together with
> any copies, from all computers.
> - It is your responsibility to scan this communication and any attached
> files
> for computer viruses and other defects and we recommend that it be
> subjected to your virus checking procedures prior to use.
> - Australian Arrow Pty. Ltd. does not accept liability for any loss or
> damage
> of any nature, howsoever caused, which may result
> directly or indirectly from this communication or any attached files.
>
>
>


RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

2013-08-15 Thread Geoff Field
> From: Geoff Field
> Sent: Friday, 16 August 2013 11:56 AM
> Thanks to everybody for their patience with my issue.  The 
> root cause is not really solved, but at least I (and my 
> colleagues) can get back to normal work patterns.
> 
> I've finally managed to get the upgrade to Apache 2.2 and SVN 
> server 1.6.9 running.  As it turns out, my former colleagues 
> had deliberately configured all the ports one up from the 
> default (thus, SSL was running on port 444 instead of the 
> default 443).  Once I'd fixed this, Apache 2.2 started 
> serving SVN via the default interfaces.
> 
> With that, I can now run everything happily.

It seems I spoke too soon.  It turns out that the updated SVN server 1.6.9 
works for those few of our repositories that are in FSFS format.  
Unfortunately, our legacy repositories are almost all in BDB format and I'm 
loathe to touch them if I can avoid it.

Building SVN from source is not really a useful option, but we can do it (with 
a struggle) if we absolutely have to.   Frankly, I'd rather convert all the 
repositories (and there are 100 all up, although some are in FSFS format 
already) than build the server code.  Has anybody built a version that handles 
BDB in a DAV module?

> I have not deleted the Apache 2.0/SVN server 1.2.3 
> configuration, so I should be able to switch back to that if 
> needed.  I suppose it's possible some repositories might 
> become inaccessible to the earlier server due to the server 
> upgrade, but I'm not particularly fussed about that.

We can swap back to the other version fairly easily if we have to, just by 
stopping Apache2.2 and starting Apache2 (or vice-versa).

Regards,

Geoff

-- 
Geoff Field
Testing Coordinator, Work Health & Safety Rep, Chief Fire Warden, First Aider
Australian Arrow Pty Ltd www.australianarrow.com.au
46 Lathams Rd, Carrum Downs, Vic, 3201, Australia
phone (+61-3) 97850597, fax (+61-3) 9785 0583
GYNET x-067-597 
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




RE: SVN 1.8.1 Errors - Show Log and Commit New Files - SOLVED (FOR ME)

2013-08-15 Thread Geoff Field
Thanks to everybody for their patience with my issue.  The root cause is not 
really solved, but at least I (and my colleagues) can get back to normal work 
patterns.

I've finally managed to get the upgrade to Apache 2.2 and SVN server 1.6.9 
running.  As it turns out, my former colleagues had deliberately configured all 
the ports one up from the default (thus, SSL was running on port 444 instead of 
the default 443).  Once I'd fixed this, Apache 2.2 started serving SVN via the 
default interfaces.

With that, I can now run everything happily.

I have not deleted the Apache 2.0/SVN server 1.2.3 configuration, so I should 
be able to switch back to that if needed.  I suppose it's possible some 
repositories might become inaccessible to the earlier server due to the server 
upgrade, but I'm not particularly fussed about that.

Regards,

Geoff

-- 
Geoff Field

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-15 Thread Geoff Field
> From: Philip Martin
> Sent: Thursday, 15 August 2013 19:02 PM
> Geoff Field writes:
> > I've just commented out the "AuthzSVNAccessFile" line and have done 
> > the following:

This time, I changed the "AuthType" line to "AuthType None" for the Subversion 
location.  Similar test (but with fewer typos this time).
C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
ASVN_Test\test7.txt
ASVN_Test\test.txt
Checked out revision 898.

C:\>cd SVN_Test

C:\SVN_Test>copy test.txt test9.txt
1 file(s) copied.

C:\SVN_Test>svn add test9.txt
A test9.txt

C:\SVN_Test>svn ci test9.txt --message "test9"
Adding test9.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test9.txt' is out of date
svn: E175005: File 'test9.txt' already exists


> > C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
> > Adding test6.txt
> > svn: E155011: Commit failed (details follow):
> > svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
> > svn: E175005: File 'test6.txt' already exists

Same error report persisting.

> > 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "CHECKOUT 
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "HEAD 
> > /Subversion/Playground/trunk/test6.txt HTTP/1.1" 401 -
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE 
> > 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> > HTTP/1.1" 401 580
> > 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE 
> > 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> > HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "DELETE 
> > 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> > HTTP/1.1" 204 -
> 
> That still shows "401 unauthorized" which is odd if you are 
> not using Authz.  Do you have some other authz beyond 
> AuthzSVNAccessFile?

It could be the SSL layer.  The location section does contain the following 
line:
  SSLRequireSSL

Still showing:
...
0.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:24 +1000] "CHECKOUT 
/Subversion/Playground/!svn/ver/898/trunk HTTP/1.1" 201 439
10.63.36.64 - - [16/Aug/2013:09:39:25 +1000] "HEAD 
/Subversion/Playground/trunk/test9.txt HTTP/1.1" 401 -
10.63.36.64 - - [16/Aug/2013:09:39:26 +1000] "DELETE 
/Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 
401 580
10.63.36.64 - - [16/Aug/2013:09:39:27 +1000] "DELETE 
/Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 
401 580
10.63.36.64 - AAPL\\gf [16/Aug/2013:09:39:27 +1000] "DELETE 
/Subversion/Playground/!svn/act/c6198893-72e5-4548-8b05-ca9a07555ac2 HTTP/1.1" 
204 -

> The 1.2.3 client simply shows that with neon we don't send HEAD.
> 
> > Again, the error log did not change.
> 
> You may get more information if you add
> 
> LogLevel debug

I did that, too.  I'll email the full results privately, as the 3000-odd lines 
resulting from this set of transactions is a bit too big for a group email.  
The final sections of the error log say this, though:
...
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1490): 
+-+
[Fri Aug 16 09:39:25 2013] [info] Subsequent (No.11) HTTPS request received for 
child 249 (server aapleng1.aapl.com.au:443)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 
bytes expected to read on BIO#1114588 [mem: 121bae8]
[Fri Aug 16 09:39:25 2013] [info] Connection to child 248 established (server 
aapleng1.aapl.com.au:443, client 10.63.36.64)
[Fri Aug 16 09:39:25 2013] [info] (70014)End of file found: SSL input filter 
read failed.
[Fri Aug 16 09:39:25 2013] [info] Seeding PRNG with 136 bytes of entropy
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1794): OpenSSL: Write: 
SSL negotiation finished successfully
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1776): OpenSSL: 
Handshake: start
[Fri Aug 16 09:39:25 2013] [info] Connection to child 249 closed with standard 
shutdown(server aapleng1.aapl.com.au:443, client 10.63.36.64)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_kernel.c(1784): OpenSSL: Loop: 
before/accept initialization
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1512): OpenSSL: read 11/11 
bytes from BIO#112df18 [mem: 52345e0] (BIO dump follows)
[Fri Aug 16 09:39:25 2013] [debug] ssl_engine_io.c(1459): 
+-+
...
[Fri Aug 16 09:39:27 2013] [info] Subsequent (No.2) HTTPS request received for 
child 248 (server aapleng1.aapl.com.au:443)
[Fri Aug 16 09:39:27 2013] [info] [client 10.63.36.64] Access granted: 
'AAPL\\gf' DELETE Playground:
[Fri Aug 16 09:39:27 2013] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 5 
bytes expected to read on BIO#112df18 [mem: 52345e0]
[Fri Aug 16 09:39:27 2013] [info] (70014)End of file found: SSL input filter 
read fa

Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-15 Thread Philip Martin
Geoff Field  writes:

> I've just commented out the "AuthzSVNAccessFile" line and have done
> the following:

> C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
> Adding test6.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
> svn: E175005: File 'test6.txt' already exists

> 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "CHECKOUT 
> /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "HEAD 
> /Subversion/Playground/trunk/test6.txt HTTP/1.1" 401 -
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> HTTP/1.1" 401 580
> 10.63.36.64 - - [15/Aug/2013:10:33:21 +1000] "DELETE 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> HTTP/1.1" 401 580
> 10.63.36.64 - AAPL\\gf [15/Aug/2013:10:33:21 +1000] "DELETE 
> /Subversion/Playground/!svn/act/fe51daff-f5fc-d84f-ada1-17b5395050b2 
> HTTP/1.1" 204 -

That still shows "401 unauthorized" which is odd if you are not using
Authz.  Do you have some other authz beyond AuthzSVNAccessFile?

The 1.2.3 client simply shows that with neon we don't send HEAD.

> Again, the error log did not change.

You may get more information if you add

LogLevel debug

-- 
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*


RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-14 Thread Geoff Field
> From: Philip Martin
> Sent: Wednesday, 14 August 2013 9:59 AM

> Geoff Field writes:
> >> When I try to reproduce the problem I get a HEAD request that 
> >> generates
> >> "404 not found" rather than "401 unauthorized".  What sort of 
> >> authentication have you configured?  Are you using 
> path-based authz?
> >
> > Here's what I think is the relevant section of our httpd.conf:
> >
> > 
> >   DAV svn
> >   SVNParentPath L:/Subversion/Repositories
> >   SVNAutoversioning on
> >
> >   AuthType SSPI
> >   AuthName "Subversion repositories"
> >   Require valid-user
> >   SSPIAuth On
> >   SSPIAuthoritative On
> >   SSPIDomain AAPL
> >   SSPIOfferBasic On
> >   SSLRequireSSL
> > #  SSPIUsernameCase lower ## Breaks authentication #  
> > SSPIPerRequestAuth Off ## This breaks Apache2
> >
> >   AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf
> >
> > Note that we're running Apache 2.0.  Here are the exact 
> details from 
> > the server's "Services" applet:
> 
> If you could disable AuthzSVNAccessFile, or move the test 
> repository to another Location that doesn't have authz, and 
> then try the commit we could determine whether Subversion's 
> authz is the problem.  The apache error log may also have 
> some relevant information about the 401.

I've just commented out the "AuthzSVNAccessFile" line and have done the 
following:
C:\>svn co  https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
ASVN_Test\test.txt
Checked out revision 897.

C:\>cd SVN_Test

C:\SVN_Test>copy test.txt test6.txt
1 file(s) copied.

C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
svn: E29: Commit failed (details follow):
svn: E29: 'C:\SVN_Test\test6.txt' is not under version control

C:\SVN_Test>svn add test6.txt
A test6.txt

C:\SVN_Test>svn ci test6.txt --message "test 1.8.1 checkin"
Adding test6.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test6.txt' is out of date
svn: E175005: File 'test6.txt' already exists

C:\SVN_Test>

That first ci is a procedural error, but I left it in for completeness.

The Apache error log DID NOT change at all.  No new entries were added by the 
test.  The new Apache access log entries are as follows:
10.63.36.69 - - [15/Aug/2013:10:31:10 +1000] "GET / HTTP/1.1" 200 28508
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 200 97
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/bln/897 HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/bln/897 HTTP/1.1" 207 481
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/bc/897/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/bc/897/trunk HTTP/1.1" 207 343
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 200 201
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "OPTIONS 
/Subversion/Playground/trunk HTTP/1.1" 200 97
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/trunk HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/trunk HTTP/1.1" 207 712
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/vcc/default HTTP/1.1" 401 580
10.63.36.64 - AAPL\\gf [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/!svn/vcc/default HTTP/1.1" 207 426
10.63.36.64 - - [15/Aug/2013:10:32:31 +1000] "PROPFIND 
/Subversion/Playground/

Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-13 Thread Philip Martin
Geoff Field  writes:

>> When I try to reproduce the problem I get a HEAD request that 
>> generates
>> "404 not found" rather than "401 unauthorized".  What sort of 
>> authentication have you configured?  Are you using path-based authz?
>
> Here's what I think is the relevant section of our httpd.conf:
>
> 
>   DAV svn
>   SVNParentPath L:/Subversion/Repositories
>   SVNAutoversioning on
>
>   AuthType SSPI
>   AuthName "Subversion repositories"
>   Require valid-user
>   SSPIAuth On
>   SSPIAuthoritative On
>   SSPIDomain AAPL
>   SSPIOfferBasic On
>   SSLRequireSSL
> #  SSPIUsernameCase lower ## Breaks authentication
> #  SSPIPerRequestAuth Off ## This breaks Apache2
>
>   AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf
>
> Note that we're running Apache 2.0.  Here are the exact details from
> the server's "Services" applet:

If you could disable AuthzSVNAccessFile, or move the test repository to
another Location that doesn't have authz, and then try the commit we
could determine whether Subversion's authz is the problem.  The apache
error log may also have some relevant information about the 401.

I don't have an Apache 2.0 build to test so I can't determine whether
the problem is related to using 2.0.  Perhaps something in 2.0 is
causing the 401 instead of a 404.

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-13 Thread Geoff Field
> From: Philip Martin
> Sent: Tuesday, 13 August 2013 19:59 PM
> Geoff Field  writes:
> >> -Original Message-
> >> From: Philip Martin
> >> Sent: Monday, 12 August 2013 18:57 PM Geoff Field writes:
> >> 
> >> I can't reproduce that.  Can you look in the apache log 
> files to see 
> >> the failed request?  Can you reproduce the problem over http?  Can 
> >> you provide a network trace?
> >
> > I have emailed Philip and Lieven directly with the network 
> trace file 
> > as it's a bit big (600-odd K) for a mailing list.
> 
> It's an https trace so not much use to me.

That's a shame.  

> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> > 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8
> > 97 HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> > 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/8
> > 97 HTTP/1.1" 207 475
> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580
> > 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> > /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> > 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "HEAD 
> > /Subversion/Playground/trunk/test4.txt HTTP/1.1" 401 -
> 
> When I try to reproduce the problem I get a HEAD request that 
> generates
> "404 not found" rather than "401 unauthorized".  What sort of 
> authentication have you configured?  Are you using path-based authz?

Here's what I think is the relevant section of our httpd.conf:


  DAV svn
  SVNParentPath L:/Subversion/Repositories
  SVNAutoversioning on

  AuthType SSPI
  AuthName "Subversion repositories"
  Require valid-user
  SSPIAuth On
  SSPIAuthoritative On
  SSPIDomain AAPL
  SSPIOfferBasic On
  SSLRequireSSL
#  SSPIUsernameCase lower ## Breaks authentication
#  SSPIPerRequestAuth Off ## This breaks Apache2

  AuthzSVNAccessFile L:\Subversion\conf\svnaccessfile.conf

Note that we're running Apache 2.0.  Here are the exact details from the 
server's "Services" applet:

 Apache/2.0.54 (Win32) DAV/2
 mod_ssl/2.0.55
 OpenSSL/0.9.8 SVN/1.2.3
 mod_python/3.1.3
 Python/2.3.5 PHP/5.0.4
 mod_auth_sspi/1.0.3

I'm trying (as a background task from my regular job) to upgrade to Apache 2.2, 
but it's proving to be a bit of a learning experience.

Part of our issue is that the people who originally set it all up (and who 
started doing the upgrade once upon a time) have moved on to other jobs.  
Another part is that maintenance of SVN is a very small part of my job - so 
small it's under "other duties as directed" in the position description, along 
with numerous other tasks.  (I guess many of us on this mailing list will be in 
similar positions, too.)

I'm still learning, even 25+ years into my work life...

Thanks for your patience.

Regards,

Geoff




- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-13 Thread Philip Martin
Geoff Field  writes:

>> -Original Message-
>> From: Philip Martin
>> Sent: Monday, 12 August 2013 18:57 PM
>> Geoff Field writes:
>> 
>> I can't reproduce that.  Can you look in the apache log files 
>> to see the failed request?  Can you reproduce the problem 
>> over http?  Can you provide a network trace?
>
> I have emailed Philip and Lieven directly with the network trace file
> as it's a bit big (600-odd K) for a mailing list.

It's an https trace so not much use to me.

> 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/897 
> HTTP/1.1" 401 580
> 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "PROPPATCH 
> /Subversion/Playground/!svn/wbl/c1ad4c6a-aab8-554c-b402-d2d0b49121e4/897 
> HTTP/1.1" 207 475
> 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 401 580
> 10.63.36.64 - AAPL\\gf [13/Aug/2013:10:51:13 +1000] "CHECKOUT 
> /Subversion/Playground/!svn/ver/897/trunk HTTP/1.1" 201 439
> 10.63.36.64 - - [13/Aug/2013:10:51:13 +1000] "HEAD 
> /Subversion/Playground/trunk/test4.txt HTTP/1.1" 401 -

When I try to reproduce the problem I get a HEAD request that generates
"404 not found" rather than "401 unauthorized".  What sort of
authentication have you configured?  Are you using path-based authz?

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-12 Thread Geoff Field
> -Original Message-
> From: Philip Martin
> Sent: Monday, 12 August 2013 18:57 PM
> Geoff Field writes:
> > Here's a log of a trial I have just done with a relatively 
> fresh repository:
> >
> > C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> > ASVN_Test\test.txt
> > Checked out revision 897.
> >
> > C:\>cd SVN_Test
> >
> > C:\SVN_Test>dir
> >  Volume in drive C is OSDisk
> >  Volume Serial Number is E49F-06D7
> >
> >  Directory of C:\SVN_Test
> >
> > 12/08/2013  09:54 AM  .
> > 12/08/2013  09:54 AM  ..
> > 12/08/2013  09:54 AM20 test.txt
> >1 File(s) 20 bytes
> >2 Dir(s)  160,268,779,520 bytes free
> >
> > C:\SVN_Test>copy test.txt test2.txt
> > 1 file(s) copied.
> >
> > C:\SVN_Test>svn add test2.txt
> > A test2.txt
> >
> > C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> > Adding test2.txt
> > svn: E155011: Commit failed (details follow):
> > svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> > svn: E175005: File 'test2.txt' already exists
> 
> I can't reproduce that.  Can you look in the apache log files 
> to see the failed request?  Can you reproduce the problem 
> over http?  Can you provide a network trace?

I have emailed Philip and Lieven directly with the network trace file as it's a 
bit big (600-odd K) for a mailing list.

Attached for general amusement and delectation is the relevant portion of our 
Apache access log for a repeat test I did this morning (Australian Eastern 
Standard Time).  The testing did not touch our Apache error log.

Regards,

Geoff

-- 
Sorry about the automatic legal disclaimer:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




ApacheAccess.log
Description: ApacheAccess.log


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-12 Thread Philip Martin
Geoff Field  writes:

> Here's a log of a trial I have just done with a relatively fresh repository:
>
> C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> ASVN_Test\test.txt
> Checked out revision 897.
>
> C:\>cd SVN_Test
>
> C:\SVN_Test>dir
>  Volume in drive C is OSDisk
>  Volume Serial Number is E49F-06D7
>
>  Directory of C:\SVN_Test
>
> 12/08/2013  09:54 AM  .
> 12/08/2013  09:54 AM  ..
> 12/08/2013  09:54 AM20 test.txt
>1 File(s) 20 bytes
>2 Dir(s)  160,268,779,520 bytes free
>
> C:\SVN_Test>copy test.txt test2.txt
> 1 file(s) copied.
>
> C:\SVN_Test>svn add test2.txt
> A test2.txt
>
> C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> Adding test2.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> svn: E175005: File 'test2.txt' already exists

I can't reproduce that.  Can you look in the apache log files to see the
failed request?  Can you reproduce the problem over http?  Can you
provide a network trace?

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-11 Thread Geoff Field
> From: Geoff Field
> Sent: Monday, 12 August 2013 10:20 AM
> > From: Philip Martin
> > Sent: Friday, 9 August 2013 18:10 PM
> > Geoff Field  writes:
> > 
> > > What about the Commit New Files error?  Will this be fixed
> > with 1.8.2,
> > > do you think?
> > 
> > I don't know how to reproduce it.  You said:
> > 
> >   Second issue: When committing new files, we get the 
> message that one 
> > of
> >   them 'already exists'.  I've found as a workaround that doing a 
> > clean
> >   checkout to a NEW directory, then copying everything across and 
> > running
> >   a commit will work - once.
> > 
> > but if I were to attempt to reproduce it I would do
> > 
> >   svnadmin create repo
> >   svn co http://localhost/repo wc
> >   cp /bin/true wc/foo  # error message was for a binary file
> >   svn add wc/foo
> >   svn ci -mm wc
> > 
> > but that works.  That's no surprise because what I have done is 
> > essentially what you say is a "workaround".  Until you can come up 
> > with a better description of how to reproduce the problem 
> not much can 
> > be done.
> 
> Hello Philip,
> 
> Sometimes the workaround works, sometimes it doesn't.
> 
> Here's a log of a trial I have just done with a relatively 
> fresh repository:
> 
> C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
> ASVN_Test\test.txt
> Checked out revision 897.
> 
> C:\>cd SVN_Test
> 
> C:\SVN_Test>dir
>  Volume in drive C is OSDisk
>  Volume Serial Number is E49F-06D7
> 
>  Directory of C:\SVN_Test
> 
> 12/08/2013  09:54 AM  .
> 12/08/2013  09:54 AM  ..
> 12/08/2013  09:54 AM20 test.txt
>1 File(s) 20 bytes
>2 Dir(s)  160,268,779,520 bytes free
> 
> C:\SVN_Test>copy test.txt test2.txt
> 1 file(s) copied.
> 
> C:\SVN_Test>svn add test2.txt
> A test2.txt
> 
> C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
> Adding test2.txt
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
> svn: E175005: File 'test2.txt' already exists
> 
> C:\SVN_Test>svn --version
> svn, version 1.8.1 (r1503906)
>compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
> 
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people; 
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
> 
> The following repository access (RA) modules are available:
> 
> * ra_svn : Module for accessing a repository using the svn 
> network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV 
> protocol using serf.
>   - handles 'http' scheme
>   - handles 'https' scheme
> 
> 
> C:\SVN_Test>
> 
> 
> Again, server version is 1.2 (yes, yes, I will update this at 
> some stage in the near future, but apparently I also have to 
> update Apache, which adds an extra layer of nuisance).
> 
> This was the first time this repository had been touched since 2009.
> 
> "test.txt" is a standard ASCII text file containing the 
> sentence "A quick test file." with one carriage return.
> 
> I hope this helps.

Oh yes, our server is running Windows Serve 2003, Enterprise Edition, SP2.

Regards,

Geoff

-- 
Apologies for the legal disclaimer auto-inserted by our servers:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-11 Thread Geoff Field
> From: Philip Martin
> Sent: Friday, 9 August 2013 18:10 PM
> Geoff Field  writes:
> 
> > What about the Commit New Files error?  Will this be fixed 
> with 1.8.2, 
> > do you think?
> 
> I don't know how to reproduce it.  You said:
> 
>   Second issue: When committing new files, we get the message 
> that one of
>   them 'already exists'.  I've found as a workaround that 
> doing a clean
>   checkout to a NEW directory, then copying everything across 
> and running
>   a commit will work - once.
> 
> but if I were to attempt to reproduce it I would do
> 
>   svnadmin create repo
>   svn co http://localhost/repo wc
>   cp /bin/true wc/foo  # error message was for a binary file
>   svn add wc/foo
>   svn ci -mm wc
> 
> but that works.  That's no surprise because what I have done 
> is essentially what you say is a "workaround".  Until you can 
> come up with a better description of how to reproduce the 
> problem not much can be done.

Hello Philip,

Sometimes the workaround works, sometimes it doesn't.

Here's a log of a trial I have just done with a relatively fresh repository:

C:\>svn co https://aapleng1/Subversion/Playground/trunk/ \SVN_Test
ASVN_Test\test.txt
Checked out revision 897.

C:\>cd SVN_Test

C:\SVN_Test>dir
 Volume in drive C is OSDisk
 Volume Serial Number is E49F-06D7

 Directory of C:\SVN_Test

12/08/2013  09:54 AM  .
12/08/2013  09:54 AM  ..
12/08/2013  09:54 AM20 test.txt
   1 File(s) 20 bytes
   2 Dir(s)  160,268,779,520 bytes free

C:\SVN_Test>copy test.txt test2.txt
1 file(s) copied.

C:\SVN_Test>svn add test2.txt
A test2.txt

C:\SVN_Test>svn ci test2.txt --message "test 1.8.1 checkin"
Adding test2.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File 'C:\SVN_Test\test2.txt' is out of date
svn: E175005: File 'test2.txt' already exists

C:\SVN_Test>svn --version
svn, version 1.8.1 (r1503906)
   compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows

Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme


C:\SVN_Test>


Again, server version is 1.2 (yes, yes, I will update this at some stage in the 
near future, but apparently I also have to update Apache, which adds an extra 
layer of nuisance).

This was the first time this repository had been touched since 2009.

"test.txt" is a standard ASCII text file containing the sentence "A quick test 
file." with one carriage return.

I hope this helps.

Regards,

Geoff
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-09 Thread Philip Martin
Geoff Field  writes:

> What about the Commit New Files error?  Will this be fixed with 1.8.2,
> do you think?

I don't know how to reproduce it.  You said:

  Second issue: When committing new files, we get the message that one of
  them 'already exists'.  I've found as a workaround that doing a clean
  checkout to a NEW directory, then copying everything across and running
  a commit will work - once.

but if I were to attempt to reproduce it I would do

  svnadmin create repo
  svn co http://localhost/repo wc
  cp /bin/true wc/foo  # error message was for a binary file
  svn add wc/foo
  svn ci -mm wc

but that works.  That's no surprise because what I have done is
essentially what you say is a "workaround".  Until you can come up with
a better description of how to reproduce the problem not much can be
done.

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-08 Thread Geoff Field
> From: Geoff Field
> Sent: Tuesday, 6 August 2013 9:33 AM
> > From: lieven.govaerts
> > On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin 
> >  wrote:
> > > Philip Martin  writes:
> > >
> > >> Lieven Govaerts  writes:
> > >>
> >  C:\Customer>svn log -v ./
> >  svn: E175002: Unexpected HTTP status 501 'Method Not
> > Implemented' 
> >  on '/Subversio
> > 
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
> > 
> >  svn: E27: Additional errors:
> >  svn: E27: The requested report is unknown.
> > 
> > Geoff, can you log an issue in our issue tracker with reference to 
> > this mail thread?
> > http://subversion.tigris.org/issue-tracker.html
> 
> Done.  Issue #4404 has been logged, specifically for the 
> first part of the issue.  Personally, I don't like reporting 
> two issues in one report, so I'll leave the other issue 
> separate - at least until I'm asked to lodge that as well.  
> At least the original issue report references some of the 
> many mailing list discussions about it.

So does the patch fix both issues?

> ...
> > >> That's easy to reproduce using 1.1.4 mod_dav_svn:
> ...
> > Can you test if attached patch fixes this issue?

What about the Commit New Files error?  Will this be fixed with 1.8.2, do you 
think?

Regards,

Geoff

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




RE: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Geoff Field
> From: lieven.govaerts
> On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin 
>  wrote:
> > Philip Martin  writes:
> >
> >> Lieven Govaerts  writes:
> >>
>  C:\Customer>svn log -v ./
>  svn: E175002: Unexpected HTTP status 501 'Method Not 
> Implemented' 
>  on '/Subversio 
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
> 
>  svn: E27: Additional errors:
>  svn: E27: The requested report is unknown.
> 
> Geoff, can you log an issue in our issue tracker with 
> reference to this mail thread?
> http://subversion.tigris.org/issue-tracker.html

Done.  Issue #4404 has been logged, specifically for the first part of the 
issue.  Personally, I don't like reporting two issues in one report, so I'll 
leave the other issue separate - at least until I'm asked to lodge that as 
well.  At least the original issue report references some of the many mailing 
list discussions about it.

> >>> For this part of your issue, I'm interested in seeing a network 
> >>> trace (wireshark, fiddler) between your client and server.

Thanks Philip.

...
> >> That's easy to reproduce using 1.1.4 mod_dav_svn:
...
> Can you test if attached patch fixes this issue?

And thanks for that Philip and Lieven.

Regards,

Geoff

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files. 




Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Philip Martin
Lieven Govaerts  writes:

>> Yes, it does.  It also affects mergeinfo:
>>
>> $ svn1.8 mergeinfo ^/ wc
>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
>> '/obj/repo/!svn/bc/1/A'
>> svn: E27: Additional errors:
>> svn: E27: The requested report is unknown.
>>
>> $ subversion/svn/svn mergeinfo ^/ wc
>> svn: E27: Retrieval of mergeinfo unsupported by 
>> 'http://localhost:/obj/repo/A'
>>
>
> To be clear, this mergeinfo error is to be expected, and this patch
> has improved the error message. Or did you see a regression here?
> Lieven

The patch changes the error message and restores the 1.7 behaviour.

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Lieven Govaerts
On Mon, Aug 5, 2013 at 7:08 PM, Philip Martin
 wrote:
> Lieven Govaerts  writes:
>
>> Can you test if attached patch fixes this issue?
>
>> Index: subversion/libsvn_ra_serf/util.c
>> ===
>> --- subversion/libsvn_ra_serf/util.c  (revision 1510435)
>> +++ subversion/libsvn_ra_serf/util.c  (working copy)
>> @@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
>>"server or an intermediate proxy does not accept "
>>"chunked encoding. Try setting 
>> 'http-chunked-requests' "
>>"to 'auto' or 'no' in your client configuration."));
>> +  case 501:
>> +return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
>> + _("The requested feature is not supported 
>> by "
>> +   "'%s'"), path);
>>  }
>>
>>if (sline.code >= 300)
>
> Yes, it does.  It also affects mergeinfo:
>
> $ svn1.8 mergeinfo ^/ wc
> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
> '/obj/repo/!svn/bc/1/A'
> svn: E27: Additional errors:
> svn: E27: The requested report is unknown.
>
> $ subversion/svn/svn mergeinfo ^/ wc
> svn: E27: Retrieval of mergeinfo unsupported by 
> 'http://localhost:/obj/repo/A'
>

To be clear, this mergeinfo error is to be expected, and this patch
has improved the error message. Or did you see a regression here?
Lieven

> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Philip Martin
Lieven Govaerts  writes:

> Can you test if attached patch fixes this issue?

> Index: subversion/libsvn_ra_serf/util.c
> ===
> --- subversion/libsvn_ra_serf/util.c  (revision 1510435)
> +++ subversion/libsvn_ra_serf/util.c  (working copy)
> @@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
>"server or an intermediate proxy does not accept "
>"chunked encoding. Try setting 'http-chunked-requests' 
> "
>"to 'auto' or 'no' in your client configuration."));
> +  case 501:
> +return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
> + _("The requested feature is not supported 
> by "
> +   "'%s'"), path);
>  }
>  
>if (sline.code >= 300)

Yes, it does.  It also affects mergeinfo:

$ svn1.8 mergeinfo ^/ wc
svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
'/obj/repo/!svn/bc/1/A'
svn: E27: Additional errors:
svn: E27: The requested report is unknown.

$ subversion/svn/svn mergeinfo ^/ wc
svn: E27: Retrieval of mergeinfo unsupported by 
'http://localhost:/obj/repo/A'

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Lieven Govaerts
On Mon, Aug 5, 2013 at 1:05 PM, Philip Martin
 wrote:
> Philip Martin  writes:
>
>> Lieven Govaerts  writes:
>>
 C:\Customer>svn log -v ./
 svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
 '/Subversio
 n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'

 svn: E27: Additional errors:
 svn: E27: The requested report is unknown.

Geoff, can you log an issue in our issue tracker with reference to
this mail thread?
http://subversion.tigris.org/issue-tracker.html

>>> For this part of your issue, I'm interested in seeing a network trace
>>> (wireshark, fiddler) between your client and server. If that's
>>> possible for you, you can send them privately. Filter out any
>>> unrelated traffic and basic/digest authentication headers if possible.
>>
>> That's easy to reproduce using 1.1.4 mod_dav_svn:
>>
>> svnadmin create repo --compatible-version 1.1
>> svn mkdir -mm file://`pwd`/repo/A
>> svn co http://localhost/repo/A wc
>> svn log -v wc
>>
>> The client is sending a get-location-segments REPORT request which is
>> new in 1.5 and not supported by earlier mod_dav_svn.
>
> In libsvn_ra/ra-loader.c:svn_ra_get_location_segments the failure of the
> get-location-segments REPORT is expected to generate
> SVN_ERR_RA_NOT_IMPLEMENTED:
>
>   if (err && (err->apr_err == SVN_ERR_RA_NOT_IMPLEMENTED))
> {
>   svn_error_clear(err);
>
>   /* Do it the slow way, using get-logs, for older servers. */
>   err = svn_ra__location_segments_from_log(session, path,
>peg_revision, start_rev,
>end_rev, receiver,
>receiver_baton, pool);
> }
>
> but libsvn_ra_serf is returning SVN_ERR_RA_DAV_REQUEST_FAILED
>
> (gdb) p err[0]
> $3 = {apr_err = 175002, message = 0x76f85e7d "traced call",
>   child = 0x77f300a0, pool = 0x77f30028,
>   file = 0x75a4ab60 
> "../src/subversion/libsvn_ra_serf/getlocationsegments.c", line = 205}
> (gdb) p err[0].child[0]
> $4 = {apr_err = 175002,
>   message = 0x77f300f0 "Unexpected HTTP status 501 'Method Not 
> Implemented' on '/obj/repo/!svn/bc/1/A'\n", child = 0x77f30140, pool = 
> 0x77f30028,
>   file = 0x75a4edf0 "../src/subversion/libsvn_ra_serf/util.c", line = 
> 2440}

Can you test if attached patch fixes this issue?

Lieven

>
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
Index: subversion/libsvn_ra_serf/util.c
===
--- subversion/libsvn_ra_serf/util.c(revision 1510435)
+++ subversion/libsvn_ra_serf/util.c(working copy)
@@ -2434,6 +2434,10 @@ svn_ra_serf__error_on_status(serf_status_line slin
   "server or an intermediate proxy does not accept "
   "chunked encoding. Try setting 'http-chunked-requests' "
   "to 'auto' or 'no' in your client configuration."));
+  case 501:
+return svn_error_createf(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
+ _("The requested feature is not supported by "
+   "'%s'"), path);
 }
 
   if (sline.code >= 300)


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Philip Martin
Philip Martin  writes:

> Lieven Govaerts  writes:
>
>>> C:\Customer>svn log -v ./
>>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
>>> '/Subversio
>>> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>>>
>>> svn: E27: Additional errors:
>>> svn: E27: The requested report is unknown.
>>
>> For this part of your issue, I'm interested in seeing a network trace
>> (wireshark, fiddler) between your client and server. If that's
>> possible for you, you can send them privately. Filter out any
>> unrelated traffic and basic/digest authentication headers if possible.
>
> That's easy to reproduce using 1.1.4 mod_dav_svn:
>
> svnadmin create repo --compatible-version 1.1
> svn mkdir -mm file://`pwd`/repo/A
> svn co http://localhost/repo/A wc
> svn log -v wc
>
> The client is sending a get-location-segments REPORT request which is
> new in 1.5 and not supported by earlier mod_dav_svn.

In libsvn_ra/ra-loader.c:svn_ra_get_location_segments the failure of the
get-location-segments REPORT is expected to generate
SVN_ERR_RA_NOT_IMPLEMENTED:

  if (err && (err->apr_err == SVN_ERR_RA_NOT_IMPLEMENTED))
{
  svn_error_clear(err);

  /* Do it the slow way, using get-logs, for older servers. */
  err = svn_ra__location_segments_from_log(session, path,
   peg_revision, start_rev,
   end_rev, receiver,
   receiver_baton, pool);
}

but libsvn_ra_serf is returning SVN_ERR_RA_DAV_REQUEST_FAILED

(gdb) p err[0]
$3 = {apr_err = 175002, message = 0x76f85e7d "traced call", 
  child = 0x77f300a0, pool = 0x77f30028, 
  file = 0x75a4ab60 
"../src/subversion/libsvn_ra_serf/getlocationsegments.c", line = 205}
(gdb) p err[0].child[0]
$4 = {apr_err = 175002, 
  message = 0x77f300f0 "Unexpected HTTP status 501 'Method Not Implemented' 
on '/obj/repo/!svn/bc/1/A'\n", child = 0x77f30140, pool = 0x77f30028, 
  file = 0x75a4edf0 "../src/subversion/libsvn_ra_serf/util.c", line = 2440}

-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Philip Martin
Lieven Govaerts  writes:

>> C:\Customer>svn log -v ./
>> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
>> '/Subversio
>> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>>
>> svn: E27: Additional errors:
>> svn: E27: The requested report is unknown.
>
> For this part of your issue, I'm interested in seeing a network trace
> (wireshark, fiddler) between your client and server. If that's
> possible for you, you can send them privately. Filter out any
> unrelated traffic and basic/digest authentication headers if possible.

That's easy to reproduce using 1.1.4 mod_dav_svn:

svnadmin create repo --compatible-version 1.1
svn mkdir -mm file://`pwd`/repo/A
svn co http://localhost/repo/A wc
svn log -v wc

The client is sending a get-location-segments REPORT request which is
new in 1.5 and not supported by earlier mod_dav_svn.

OPTIONS /obj/repo/A HTTP/1.1
Host: localhost:
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Connection: keep-alive
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Content-Length: 131

HTTP/1.1
 200 OK
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
DAV: 1
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,CHECKOUT
Content-Length: 188
Keep-Alive: timeout=5
Connection: Keep-Alive
Content-Type: text/xml; charset="utf-8"



/obj/repo/!svn/act/
OPTIONS /obj/repo/A HTTP/1.1
Host: localhost:
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked

42

0

HTTP/1.1 200 OK
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
DAV: 1
DAV: version-control,checkout,working-resource
DAV: merge,baseline,activity,version-controlled-collection
MS-Author-Via: DAV
Allow: OPTIONS,GET,HEAD,POST,DELETE,TRACE,PROPFIND,PROPPATCH,COPY,MOVE,CHECKOUT
Content-Length: 97
Content-Type: text/xml; charset="utf-8"




PROPFIND /obj/repo/A HTTP/1.1
Host: localhost:
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Depth: 0
Transfer-Encoding: chunked

12c
http://subversion.tigris.org/xmlns/dav/"/>http://subversion.tigris.org/xmlns/dav/"/>
0

HTTP/1.1 207 Multi-Status
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Content-Length: 678
Content-Type: text/xml; charset="utf-8"


http://subversion.tigris.org/xmlns/dav/"; xmlns:ns0="DAV:">
http://subversion.tigris.org/xmlns/dav/";>
/obj/repo/A/


/obj/repo/!svn/vcc/default

A
71d71533-4707-4b1a-86cb-88d8fd12bffd

HTTP/1.1 200 OK



PROPFIND /obj/repo/!svn/vcc/default HTTP/1.1
Host: localhost:
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Depth: 0
Label: 1
Transfer-Encoding: chunked

94

0

HTTP/1.1 207 Multi-Status
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Vary: Label
Content-Length: 449
Content-Type: text/xml; charset="utf-8"



http://subversion.tigris.org/xmlns/dav/";>
/obj/repo/!svn/bln/1


/obj/repo/!svn/bc/1/
1

HTTP/1.1 200 OK



REPORT /obj/repo/!svn/bc/1/A HTTP/1.1
Host: localhost:
User-Agent: SVN/1.8.2-dev (x86_64-unknown-linux-gnu) serf/1.2.2
Content-Type: text/xml
Accept-Encoding: gzip
DAV: http://subversion.tigris.org/xmlns/dav/svn/depth
DAV: http://subversion.tigris.org/xmlns/dav/svn/mergeinfo
DAV: http://subversion.tigris.org/xmlns/dav/svn/log-revprops
Transfer-Encoding: chunked

bd
110
0

HTTP/1.1 501 Method Not Implemented
Date: Mon, 05 Aug 2013 10:28:38 GMT
Server: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e DAV/2 SVN/1.1.4
Content-Length: 228
Connection: close
Content-Type: text/xml; charset="utf-8"


http://apache.org/dav/xmlns"; xmlns:C="svn:">


The requested report is unknown.






-- 
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Lieven Govaerts
Hi,

On Fri, Aug 2, 2013 at 2:06 AM, Geoff Field  wrote:
> I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its 
> command-line basis.  Our server has been running 1.2 and has not been changed 
> (apart from Windows updates) for a LONG time.
>
> (Yes, I know 1.2 is very old.  However, we're an automotive company and 
> changes to our tools can result in issues with customer approvals.  
> Nonetheless, an upgrade is on the "to-do" list.)

A 1.8 client should have no problem communicating with any svn 1.x
server, so if that doesn't hold anymore for a 1.2 server then that's a
bug we want to fix.

> Having said that, there are now MANY people posting to the TSVN mailing list 
> about these two issues.
>
> My platforms are 32-bit Windows 7 and Windows XP, but it has also been 
> reported on 64-bit Windows.
>
>
> First issue: When doing a "Show Log", the client says it can't contact the 
> server and asks if people (including us) want to go offline, then puts up an 
> HTTP 501 error.
>
> Second issue: When committing new files, we get the message that one of them 
> 'already exists'.  I've found as a workaround that doing a clean checkout to 
> a NEW directory, then copying everything across and running a commit will 
> work - once.
>
>
> After discussions on the TSVN mailing list, I've run command-line versions of 
> both, with the following results (edited to hide customer names):
>
> C:\Customer>svn log -v ./
> svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on 
> '/Subversio
> n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'
>
> svn: E27: Additional errors:
> svn: E27: The requested report is unknown.

For this part of your issue, I'm interested in seeing a network trace
(wireshark, fiddler) between your client and server. If that's
possible for you, you can send them privately. Filter out any
unrelated traffic and basic/digest authentication headers if possible.

Lieven

> C:\Customer>svn commit ./ -m "Committing via command line"
> Adding  (bin)  DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx
> svn: E155011: Commit failed (details follow):
> svn: E155011: File 
> 'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr
> lLimits.xlsx' is out of date
> svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists
>
> C:\Customer>svn --version
> svn, version 1.8.1 (r1503906)
>compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows
>
> Copyright (C) 2013 The Apache Software Foundation.
> This software consists of contributions made by many people;
> see the NOTICE file for more information.
> Subversion is open source software, see http://subversion.apache.org/
>
> The following repository access (RA) modules are available:
>
> * ra_svn : Module for accessing a repository using the svn network protocol.
>   - with Cyrus SASL authentication
>   - handles 'svn' scheme
> * ra_local : Module for accessing a repository on local disk.
>   - handles 'file' scheme
> * ra_serf : Module for accessing a repository via WebDAV protocol using serf.
>   - handles 'http' scheme
>   - handles 'https' scheme
>
> Regards,
>
> Geoff
>


Re: SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Ryan Schmidt

On Aug 1, 2013, at 19:06, Geoff Field  wrote:

> I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its 
> command-line basis. Our server has been running 1.2 and has not been changed 
> (apart from Windows updates) for a LONG time.
> 
> (Yes, I know 1.2 is very old.  However, we're an automotive company and 
> changes to our tools can result in issues with customer approvals.  
> Nonetheless, an upgrade is on the "to-do" list.)

It has been a longstanding policy of the Subversion project at any given time 
to support the latest major version and the previous major version. Therefore 
at this time Subversion < 1.7 is no longer supported. You should attempt to 
reproduce the issue with the server running Subversion 1.7 or later.

If you cannot upgrade the real server to 1.7 or later yet, you could set up a 
test server elsewhere, for example on your workstation, to see if upgrading 
would help with this problem. On the old server, you could "svnadmin dump" the 
repository into a file and then "svnadmin load" that file into your newer test 
server. Then see if you still experience the problem when you check out your 
working copies from the test server.




SVN 1.8.1 Errors - Show Log and Commit New Files

2013-08-05 Thread Geoff Field
I have recently updated to TSVN 1.8.1, which of course uses SVN 1.8.1 as its 
command-line basis.  Our server has been running 1.2 and has not been changed 
(apart from Windows updates) for a LONG time.

(Yes, I know 1.2 is very old.  However, we're an automotive company and changes 
to our tools can result in issues with customer approvals.  Nonetheless, an 
upgrade is on the "to-do" list.)

Having said that, there are now MANY people posting to the TSVN mailing list 
about these two issues.

My platforms are 32-bit Windows 7 and Windows XP, but it has also been reported 
on 64-bit Windows.


First issue: When doing a "Show Log", the client says it can't contact the 
server and asks if people (including us) want to go offline, then puts up an 
HTTP 501 error.

Second issue: When committing new files, we get the message that one of them 
'already exists'.  I've found as a workaround that doing a clean checkout to a 
NEW directory, then copying everything across and running a commit will work - 
once.


After discussions on the TSVN mailing list, I've run command-line versions of 
both, with the following results (edited to hide customer names):

C:\Customer>svn log -v ./
svn: E175002: Unexpected HTTP status 501 'Method Not Implemented' on '/Subversio
n/W3000_Customer_198.622-00_Customer_DRL/!svn/bc/14/trunk/03_Software'

svn: E27: Additional errors:
svn: E27: The requested report is unknown.

C:\Customer>svn commit ./ -m "Committing via command line"
Adding  (bin)  DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDrlLimits.xlsx
svn: E155011: Commit failed (details follow):
svn: E155011: File 
'C:\Customer\DRL_FT\ProjectWorkSpace\OtherInputFiles\CustomerDr
lLimits.xlsx' is out of date
svn: E175005: File 'OtherInputFiles/CustomerDrlLimits.xlsx' already exists

C:\Customer>svn --version
svn, version 1.8.1 (r1503906)
   compiled Jul 22 2013, 18:46:03 on x86-microsoft-windows

Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

Regards,

Geoff

-- 
Geoff Field

- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files.