Re: Proxy error on SVN 1.8.1

[Lieven Govaerts]

Hi,

On Wed, Jul 31, 2013 at 11:30 AM, Guillaume Lasnier
 wrote:
> Hi Lieven,
> Please find attached the tcpdump that dumps traffic between my laptop and
> the proxy. The only information I could get about the proxy is that it's
> an ISA server.

from the trace I don't really see what's going on, the proxy returns
200 Connection Established so the ssl tunnel was setup correctly,
including proxy authentication.

Now I see that homebrew provides serf 1.2.1, also for Subversion 1.8.1
(*). Serf 1.3.0 is available which includes many fixes for the ssl
tunnel and authentication code. So I propose that you test with serf
1.3.0 first. You'll have to build svn and serf manually or wait for
the homebrew project to update serf to 1.3.0.

Note: your username and password can be extract from the trace you
sent, I suggest you change them.

Lieven

(*) https://github.com/mxcl/homebrew/commits/master/Library/Formula/serf.rb

>
> Regards
>
> --
> Guillaume Lasnier
>
>
>
> On 7/29/13 7:01 PM, "Lieven Govaerts"  wrote:
>
>>Hi,
>>
>>On Mon, Jul 29, 2013 at 6:28 PM, Guillaume Lasnier
>> wrote:
>>> Hi all,
>>> When issuing the following command, I get the following error:
>>>
>>> $ svn -v log
>>> svn: E120107: Unable to connect to a repository at URL
>>> 'https://svncvs.myhost.mydomain/repos/myrepo/trunk/hybris/bin/platform'
>>> svn: E120107: Error running context: The proxy server returned an error
>>> while setting up the SSL tunnel.
>>
>>That error indicates the proxy returned an error to the CONNECT
>>request that svn uses to initiate the ssl tunnel.
>>What proxy server do you use? KeepAlive off? Specific authentication?
>>
>>I think the easiest way to find out what's going on is to trace the
>>network traffic. Can you make a trace with fiddler or wireshark?
>>
>>>
>>> I am using subversion 1.8.1 on Mac OS X installed with homebrew.
>>> I have configured the proxy the following way in ~/.subversion/servers :
>>>
>>> [groups]
>>> # group1 = *.collab.net
>>> # othergroup = repository.blarggitywhoomph.com
>>> # thirdgroup = *.example.com
>>> mygroup = *.myhost.mydomain
>>>
>>> # Information for my group:
>>> [mygroup]
>>> http-proxy-host = 192.168.xxx.xxx
>>> http-proxy-port = 1234
>>> http-proxy-username = john
>>> http-proxy-password = doe
>>>
>>>
>>> This configuration used to work with subversion 1.7.
>>>
>>Configuration looks ok, and if it has worked before then we should be
>>able to make it work in 1.8.1 too.
>>
>>Lieven
>>
>>
>>> Do have any idea?
>>>
>>> --
>>>
>>> Guillaume Lasnier
>>>
>>>
>>>
>>>
>

Cope with IPv6

[Okabayashi, Hirotsugu]

Dear User Support,

Could you tell us the specifications about the authentication with IPv6 ?
These behavior bothers us about IPv6.
 -When connecting to SVN server with IPv6, the client tool(TortoiseSVN:TSVN) 
can't handle the authentication operation.
 -Only with IPv6, the Operating system handle the authentication. So, both 
authenticated case and not authenticated case,
  TSVN doesn't work. TSVN display the same error message.

At first, we thought the problem causes TSVN's specification.
But, the TSVN's user support said the authentication is handled by the SVN's 
API and the serf library.
So, they said the problem relates to SVN's API and the serf library's 
specification.

With IPv6, do SVN's API and the serf library work well when authenticating?

Regards,

**
Sony Global Solutions Inc.
Hirotsugu Okabayashi
Tel: 03-5479-6566
Mail:
**

SVN 1.8.1 Errors - Show Log and Commit New Files

[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. 

Re: Cope with IPv6

[Thorsten Schöning]

Guten Tag Okabayashi, Hirotsugu,
am Montag, 5. August 2013 um 09:17 schrieben Sie:

>  -Only with IPv6, the Operating system handle the authentication.

What does this mean?

> So, both authenticated case and not authenticated case,
>   TSVN doesn't work. TSVN display the same error message.

You should at least provide the error message you get, but there are
surely some more interesting details: How are your repos served,
svnadmin, httpd, SSH? The mention of serf implies httpd, so you could
provide some more details about if your are using proxys etc.

I'm none of the developers but from my understanding of IPv6 it
shouldn't have any influence on the authentication itself as this is
handled in layers above the addressing and communication.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow

Re: SVN FSFS format value for 1.8?

[Ryan Schmidt]

On Aug 4, 2013, at 21:27, Thomas Harold wrote:

> On 8/4/2013 6:30 PM, Ryan Schmidt wrote:
> 
>> Check the file /backup/svndump/test3/db/format.
> 
> # cat /backup/svndump/test3/db/format
> 6
> layout sharded 1000
> 
> Okay, so I was looking at the wrong thing.
> 
> That still raises the question (in my mind) of why the two values are 
> different on a freshly created repository.
> 
> # svnadmin create test4
> # cat test4/format
> 5
> # cat test4/db/format
> 6
> layout sharded 1000
> 
> Or is the "format" file in the root used for something else?

Yes, the two files have different purposes.

repo/format describes the format of the repository.

repo/db/format describes the format of the repository filesystem.

http://serverfault.com/questions/277441/difference-between-the-format-and-db-format-files-in-a-subversion-repository

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

[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.

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

[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
>

subversion fails to detect correct merge direction (sync/reintegrate), how to override?

[Grabner Markus]

Hi all!

The new "automatic merge" feature in subversion 1.8 look promising, but in our 
case prevents merging the trunk into a branch since subversion incorrectly 
interprets this operation as a reintegration merge and complains about missing 
revisions which should have been merged first. I can force the merge by 
explicitly selecting the range of revisions not yet merged, but this is exactly 
what merge tracking should do for me. So I have two questions:

*) Is it possible to override subversion's decision on the merge type (i.e., 
force a sync merge)?

*) What could be the source of confusion which leads to the incorrect merge 
classification? Maybe some complex and/or broken svn:mergeinfo property?

Thanks & kind regards,
Markus


Dr. Markus Grabner
Research Department / Algorithms

phone +43 (0) 316 403010 761
fax +43 (0) 316 403010 711
markus.grab...@alicona.com
www.alicona.com

Alicona Imaging GmbH - optical 3D measurement and inspection - Dr.-Auner-Straße 
21a - 8074 Raaba/Graz - Austria

Registered office: Grambach, FN 208097a, Landesgericht für ZRS Graz / This 
e-mail may contain privileged and/or confidential information. If you receive 
this email in error or are not the intended recipient, you may not use, copy, 
disseminate or distribute it. Do not open any attachments, delete it 
immediately from your system and notify the sender promptly by email that you 
have done so.

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

[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

[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

Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Konstantin Kolosovsky]

Hi Everyone,

I've got a question about "--non-interactive" and "--force-interactive" 
flags behavior in Subversion 1.8.
I'm not subscribed to the mailing list, please put my email in Cc in any 
responses.


We've got java application interacting with svn.exe command line 
utility. For Subversion 1.7 our authentication behavior was the following:

- executing command using svn.exe, for instance "svn udpate"
- getting "authentication realm" from process output
- destroying process
- creating correct credential cache for the obtained "authentication 
realm" (for instance, correct file with encrypted password in the "auth" 
folder for Windows)
- executing command using svn.exe once again - so that authentication 
goes smoothly as necessary information is in credential cache


With Subversion 1.8 client we can not get "authentication realm" to 
create correct credential cache information:
- if not specifying "--force-interactive" flag or specifying 
"--non-interactive" flag - process output contains authentication 
failure message, but only with repository url - not the "authentication 
realm"
- if specifying "--force-interactive" flag - process "hangs" not 
providing any output - so there is no way to get "authentication realm" 
from it and then destroy the process


So the question is - is it possible to somehow return previous behavior 
of svn.exe client - so that it does not "hang" but just "waiting" for 
the "user input" providing necessary "authentication realm" in the output?
Or what would you recommend in such situation when authentication is 
necessary when interacting with svn.exe utility from java application? 
Is directly specifying "--username" and "--password" keys the only 
available option?


Many thanks,
Konstantin

--
Konstantin Kolosovsky
Software Developer
JetBrains
http://www.jetbrains.com
"Develop with pleasure!"

TortoiseSVN 1.8.1 build 24570 - not showing log entries since updating to 1.8.1 64-bit Windows 7

[Alison Sissins]

I notice that there are several entries in the users community concerning 
viewing log entries since upgrading to subversion 1.8.1 64-bit version, I would 
like to backup their issue.

Since updating my machine to 1.8.1 build 24570 64-bit on the 25th July,  
although I can commit, I cannot see any log entries since the 25th July, even 
when using the repro-browser.  On the Log dialogue, there is a "From:" and a 
"To: " calendar at the top RHS. The calendar  date cannot select anything after 
25th July.
The check boxes at the bottom are not ticked.

$ svn info url
$ svn list -v url
$ svn log -v url

All of these commands work and display the recent  entries I have made since 
the 25th July. Although I installed the 32-bit version of collabnet svn.

The 32-bit  SVN client I run in the Windows-xp virtual PC machine which also 
has   1.8.1 build 24570 installed can see the log entries.

Another 64-bit windows 7 with TortoiseSVN 1.7.11, Build 23600 - 64 Bit can see 
the log entries.

I think it is a problem with the 64-bit version of 1.8.1?

Kind regards

Alison



Alison Sissins | Analyst/Programmer
N J Froment & Co Limited | Easton-on-the-Hill | STAMFORD | PE9 3NP | United 
Kingdom
T +44 (0) 1780 480033 | F +44 (0) 1780 480044
www.Froment.co.uk 
www.EmersonNetworkPower.com

This message is from N J Froment & Co Limited ("The Company") whose registered 
office is at Easton-on-the-Hill, STAMFORD, PE9 3NP, United Kingdom. Registered 
in England No 1102856. VAT Registration No GB120658784.
The Company owns the copyright of this e-mail message including any attached 
files that the Company has created. This message may contain information that 
is confidential and intended for a specific addressee and purpose. If you are 
not an intended addressee you are not authorised to read, copy, print, forward, 
or take any other action based on the information.




Message from: a...@froment.co.uk
Message to: users@subversion.apache.org
Attached files:0

Re: TortoiseSVN 1.8.1 build 24570 - not showing log entries since updating to 1.8.1 64-bit Windows 7

[Andy Levy]

On Mon, Aug 5, 2013 at 5:57 AM, Alison Sissins  wrote:
> I notice that there are several entries in the users community concerning
> viewing log entries since upgrading to subversion 1.8.1 64-bit version, I
> would like to backup their issue.
>
>
>
> Since updating my machine to 1.8.1 build 24570 64-bit on the 25th July,
> although I can commit, I cannot see any log entries since the 25th July,
> even when using the repro-browser.  On the Log dialogue, there is a ”From:”
> and a “To: “ calendar at the top RHS. The calendar  date cannot select
> anything after 25th July.
>
> The check boxes at the bottom are not ticked.
>
>
>
> $ svn info url
> $ svn list -v url
> $ svn log -v url
>
>
>
> All of these commands work and display the recent  entries I have made since
> the 25th July. Although I installed the 32-bit version of collabnet svn.
>
>
>
> The 32-bit  SVN client I run in the Windows-xp virtual PC machine which also
> has   1.8.1 build 24570 installed can see the log entries.
>
>
>
> Another 64-bit windows 7 with TortoiseSVN 1.7.11, Build 23600 - 64 Bit can
> see the log entries.
>
>
>
> I think it is a problem with the 64-bit version of 1.8.1?


I cannot reproduce the behaviour. TSVN 1.8.1 64-bit on Win7, all logs
are working properly.

Did you reboot after installing 1.8.1?

Have you tried disabling log caching, or clearing the log cache?

Since this appears to be specific to TSVN, you should probably jump
over to the TSVN Users mailing list (I've added them to the CC list).
http://tortoisesvn.net/community.html

Re: Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Branko Čibej]

On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
> Hi Everyone,
>
> I've got a question about "--non-interactive" and
> "--force-interactive" flags behavior in Subversion 1.8.
> I'm not subscribed to the mailing list, please put my email in Cc in
> any responses.
>
> We've got java application interacting with svn.exe command line
> utility. For Subversion 1.7 our authentication behavior was the following:
> - executing command using svn.exe, for instance "svn udpate"
> - getting "authentication realm" from process output
> - destroying process
> - creating correct credential cache for the obtained "authentication
> realm" (for instance, correct file with encrypted password in the
> "auth" folder for Windows)
> - executing command using svn.exe once again - so that authentication
> goes smoothly as necessary information is in credential cache
>
> With Subversion 1.8 client we can not get "authentication realm" to
> create correct credential cache information:
> - if not specifying "--force-interactive" flag or specifying
> "--non-interactive" flag - process output contains authentication
> failure message, but only with repository url - not the
> "authentication realm"
> - if specifying "--force-interactive" flag - process "hangs" not
> providing any output - so there is no way to get "authentication
> realm" from it and then destroy the process
>
> So the question is - is it possible to somehow return previous
> behavior of svn.exe client - so that it does not "hang" but just
> "waiting" for the "user input" providing necessary "authentication
> realm" in the output?
> Or what would you recommend in such situation when authentication is
> necessary when interacting with svn.exe utility from java application?
> Is directly specifying "--username" and "--password" keys the only
> available option?

If you use --force-interactive, you're telling Subversion to prompt the
terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
last resort. So for scripting the command-line client the way you're
doing, I'd recommend to pass --non-interactive and --username and
--password.

The better option of course is to just use the JavaHL API instead.

-- Brane


-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Re: Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Mark Phippard]

On Mon, Aug 5, 2013 at 10:03 AM, Branko Čibej  wrote:
> On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
>> Hi Everyone,
>>
>> I've got a question about "--non-interactive" and
>> "--force-interactive" flags behavior in Subversion 1.8.
>> I'm not subscribed to the mailing list, please put my email in Cc in
>> any responses.
>>
>> We've got java application interacting with svn.exe command line
>> utility. For Subversion 1.7 our authentication behavior was the following:
>> - executing command using svn.exe, for instance "svn udpate"
>> - getting "authentication realm" from process output
>> - destroying process
>> - creating correct credential cache for the obtained "authentication
>> realm" (for instance, correct file with encrypted password in the
>> "auth" folder for Windows)
>> - executing command using svn.exe once again - so that authentication
>> goes smoothly as necessary information is in credential cache
>>
>> With Subversion 1.8 client we can not get "authentication realm" to
>> create correct credential cache information:
>> - if not specifying "--force-interactive" flag or specifying
>> "--non-interactive" flag - process output contains authentication
>> failure message, but only with repository url - not the
>> "authentication realm"
>> - if specifying "--force-interactive" flag - process "hangs" not
>> providing any output - so there is no way to get "authentication
>> realm" from it and then destroy the process
>>
>> So the question is - is it possible to somehow return previous
>> behavior of svn.exe client - so that it does not "hang" but just
>> "waiting" for the "user input" providing necessary "authentication
>> realm" in the output?
>> Or what would you recommend in such situation when authentication is
>> necessary when interacting with svn.exe utility from java application?
>> Is directly specifying "--username" and "--password" keys the only
>> available option?
>
> If you use --force-interactive, you're telling Subversion to prompt the
> terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
> last resort. So for scripting the command-line client the way you're
> doing, I'd recommend to pass --non-interactive and --username and
> --password.
>
> The better option of course is to just use the JavaHL API instead.

I have seen this problem as well.  We have a Java server application
that scripts the command line so that it can retrieve and accept the
SSL certificate.  We added the new --force-interactive option but the
problem is that the prompting seems to happen in the process that
started the Java server application instead of in the application
itself. So it is no longer possible to capture the command line output
with the certificate details and accept it.

Personally, I think this is a regression and not an improvement.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Branko Čibej]

On 05.08.2013 16:12, Mark Phippard wrote:
> On Mon, Aug 5, 2013 at 10:03 AM, Branko Čibej  wrote:
>> On 05.08.2013 12:14, Konstantin Kolosovsky wrote:
>>> Hi Everyone,
>>>
>>> I've got a question about "--non-interactive" and
>>> "--force-interactive" flags behavior in Subversion 1.8.
>>> I'm not subscribed to the mailing list, please put my email in Cc in
>>> any responses.
>>>
>>> We've got java application interacting with svn.exe command line
>>> utility. For Subversion 1.7 our authentication behavior was the following:
>>> - executing command using svn.exe, for instance "svn udpate"
>>> - getting "authentication realm" from process output
>>> - destroying process
>>> - creating correct credential cache for the obtained "authentication
>>> realm" (for instance, correct file with encrypted password in the
>>> "auth" folder for Windows)
>>> - executing command using svn.exe once again - so that authentication
>>> goes smoothly as necessary information is in credential cache
>>>
>>> With Subversion 1.8 client we can not get "authentication realm" to
>>> create correct credential cache information:
>>> - if not specifying "--force-interactive" flag or specifying
>>> "--non-interactive" flag - process output contains authentication
>>> failure message, but only with repository url - not the
>>> "authentication realm"
>>> - if specifying "--force-interactive" flag - process "hangs" not
>>> providing any output - so there is no way to get "authentication
>>> realm" from it and then destroy the process
>>>
>>> So the question is - is it possible to somehow return previous
>>> behavior of svn.exe client - so that it does not "hang" but just
>>> "waiting" for the "user input" providing necessary "authentication
>>> realm" in the output?
>>> Or what would you recommend in such situation when authentication is
>>> necessary when interacting with svn.exe utility from java application?
>>> Is directly specifying "--username" and "--password" keys the only
>>> available option?
>> If you use --force-interactive, you're telling Subversion to prompt the
>> terminal, if any -- as of 1.8, prompting on stdin/stderr is only the
>> last resort. So for scripting the command-line client the way you're
>> doing, I'd recommend to pass --non-interactive and --username and
>> --password.
>>
>> The better option of course is to just use the JavaHL API instead.
> I have seen this problem as well.  We have a Java server application
> that scripts the command line so that it can retrieve and accept the
> SSL certificate.  We added the new --force-interactive option but the
> problem is that the prompting seems to happen in the process that
> started the Java server application instead of in the application
> itself. So it is no longer possible to capture the command line output
> with the certificate details and accept it.

It has nothing to do with processes. We prompt the terminal, and read
responses from the terminal, instead of using stderr for the prompt and
stdin for the response. Note that on Windows, this was always the case
for certain kinds of prompts. 1.8 merely makes that consistent.

> Personally, I think this is a regression and not an improvement.

You had a year and a half to raise this on dev@. :)

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com

Merge order affects final result for repeated added & deleted changes

[Fredrik Orderud]

There seems to be a problem with the merge logic in SVN when merging
repeated added & deleted changes out-of-order.

Example activity on branch A:
r1: A new file is added.
r2: A line is added
r3: The line is removed
r4: The line is re-added
Later activity on branch B (created from A@r1):
r5: r2 and r4 are merged in.
r6: r3 is merged in.

What happens in r5 is that repeated merging of the same change does _not_
cause duplication or merge conflict. Instead, r4 seems to be ignored. The
end result after r6 (a complete merge) is that r4 is missing from branch B.
This is inconsistent with svn:mergeinfo which claims that it has been
merged. Patches to reproduce are attached.

Could it be possible to make svn merges fail on repeated merges of the same
change, instead of just ignoring them?

The problem was reproduced using svn 1.8.1 (command-line) client on Win7
64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win
server 2008 R2.

Thanks in advance,
Fredrik Orderud
Index: Test.cpp
===
--- Test.cpp(revision 0)
+++ Test.cpp(revision 1)
@@ -0,0 +1 @@
+First line

Index: Test.cpp
===
--- Test.cpp(revision 1)
+++ Test.cpp(revision 2)
@@ -1 +1,2 @@
 First line
+Second line

Index: Test.cpp
===
--- Test.cpp(revision 2)
+++ Test.cpp(revision 3)
@@ -1,2 +1 @@
 First line
-Second line

Index: Test.cpp
===
--- Test.cpp(revision 3)
+++ Test.cpp(revision 4)
@@ -1 +1,2 @@
 First line
+Second line

RE: TortoiseSVN 1.8.1 build 24570 - not showing log entries since updating to 1.8.1 64-bit Windows 7 - solved

[Alison Sissins]

Many thanks for your reply.
Although the repository was not in the list of cached repositories I deleted 
the repositories listed, and unticked the "Enable log caching", and now the 
complete log history is there.
Kind regards
Alison



Alison Sissins | Analyst/Programmer
N J Froment & Co Limited | Easton-on-the-Hill | STAMFORD | PE9 3NP | United 
Kingdom
T +44 (0) 1780 480033 | F +44 (0) 1780 480044
http://www.froment.co.uk/ http://www.EmersonNetworkPower.com

This message is from N J Froment & Co Limited ("The Company") whose registered 
office is at Easton-on-the-Hill, STAMFORD, PE9 3NP, United Kingdom. Registered 
in England No 1102856. VAT Registration No GB120658784.
The Company owns the copyright of this e-mail message including any attached 
files that the Company has created. This message may contain information that 
is confidential and intended for a specific addressee and purpose. If you are 
not an intended addressee you are not authorised to read, copy, print, forward, 
or take any other action based on the information.

-Original Message-

From: Andy Levy [mailto:andy.l...@gmail.com]
Sent: 05 August 2013 14:42
To: Alison Sissins
Cc: users@subversion.apache.org; users
Subject: Re: TortoiseSVN 1.8.1 build 24570 - not showing log entries since 
updating to 1.8.1 64-bit Windows 7

On Mon, Aug 5, 2013 at 5:57 AM, Alison Sissins  wrote:
> I notice that there are several entries in the users community
> concerning viewing log entries since upgrading to subversion 1.8.1
> 64-bit version, I would like to backup their issue.
>
>
>
> Since updating my machine to 1.8.1 build 24570 64-bit on the 25th
> July, although I can commit, I cannot see any log entries since the
> 25th July, even when using the repro-browser.  On the Log dialogue, there is 
> a "From:"
> and a "To: " calendar at the top RHS. The calendar  date cannot select
> anything after 25th July.
>
> The check boxes at the bottom are not ticked.
>
>
>
> $ svn info url
> $ svn list -v url
> $ svn log -v url
>
>
>
> All of these commands work and display the recent  entries I have made
> since the 25th July. Although I installed the 32-bit version of collabnet svn.
>
>
>
> The 32-bit  SVN client I run in the Windows-xp virtual PC machine which also
> has   1.8.1 build 24570 installed can see the log entries.
>
>
>
> Another 64-bit windows 7 with TortoiseSVN 1.7.11, Build 23600 - 64 Bit
> can see the log entries.
>
>
>
> I think it is a problem with the 64-bit version of 1.8.1?


I cannot reproduce the behaviour. TSVN 1.8.1 64-bit on Win7, all logs are 
working properly.

Did you reboot after installing 1.8.1?

Have you tried disabling log caching, or clearing the log cache?

Since this appears to be specific to TSVN, you should probably jump over to the 
TSVN Users mailing list (I've added them to the CC list).
http://tortoisesvn.net/community.html


Message from: a...@froment.co.uk
Message to: us...@tortoisesvn.tigris.org, users@subversion.apache.org, 
andy.l...@gmail.com
Attached files:0

Re: Subversion 1.8 "--non-interactive" and "--force-interactive" flags behavior

[Mark Phippard]

On Mon, Aug 5, 2013 at 10:20 AM, Branko Čibej  wrote:

>>> The better option of course is to just use the JavaHL API instead.
>> I have seen this problem as well.  We have a Java server application
>> that scripts the command line so that it can retrieve and accept the
>> SSL certificate.  We added the new --force-interactive option but the
>> problem is that the prompting seems to happen in the process that
>> started the Java server application instead of in the application
>> itself. So it is no longer possible to capture the command line output
>> with the certificate details and accept it.
>
> It has nothing to do with processes. We prompt the terminal, and read
> responses from the terminal, instead of using stderr for the prompt and
> stdin for the response. Note that on Windows, this was always the case
> for certain kinds of prompts. 1.8 merely makes that consistent.
>
>> Personally, I think this is a regression and not an improvement.
>
> You had a year and a half to raise this on dev@. :)

When the changes were made I just assumed Java apps would still work.
I assumed the code would just see the JVM as being the terminal.  I
also generally trust the dev team to not introduce regressions.  Guess
I was wrong on both counts.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

[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

[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 migration - directory deltification and revprop packing

[Thomas Harold]

On 8/2/2013 3:21 PM, Thomas Harold wrote:

Our migration process:

>
> 0. svnadmin verify oldreponame


1. svnadmin dump oldreponame

2. svnadmin create newreponame

3. Modify db/fsfs.conf

[rep-sharing]
enable-rep-sharing = true # defaults to true in 1.8

[deltification]
enable-dir-deltification = true
enable-props-deltification = true

This can be done in automated fashion with sed (or awk).

sed 's/^[#[:space:]]*enable-rep-sharing =
false[#[:space:]]*$/enable-rep-sharing =
true/g;s/^[#[:space:]]*enable-dir-deltification =
false[#[:space:]]*$/enable-dir-deltification =
true/g;s/^[#[:space:]]*enable-props-deltification =
false[#[:space:]]*$/enable-props-deltification = true/g' --in-place=bkp
newreponame/db/fsfs.conf

Naturally, you should have a backup of your db/fsfs.conf file.  While
sed creates one with --in-place=bkp, you should not rely solely on that
method.

4. svnadmin load newreponame

5. svnadmin pack newreponame
- Not all of our repos were packed



Sample repository size changes for us:

OLD: Size: 52MB Files: 1310
NEW: Size: 52MB Files: 1313
- This one is a lot of "add file, then remove it a few days later 
without modifications".


OLD: Size: 151MB Files: 18574
NEW: Size: 60MB Files: 633
- Apache HTTP log files stored with FSVS, 40% of original size

OLD: Size: 151MB Files: 2540
NEW: Size: 126MB Files: 551
- Linux server configuration, stored using FSVS, 83% of original

OLD: Size: 473MB Files: 600
NEW: Size: 424MB Files: 603
- Another FSVS repository, 90% of original

OLD: Size: 1080MB Files: 2582
NEW: Size: 964MB Files: 1785
- FSVS repository, 69% of original

I haven't seen any repositories bloat up to larger then the original 
size, but I'm still working through converting our old v1.6 repositories 
to the v1.8 format.


The bottlenecks for us in the dump/load cycle are:
- CPU for "svnadmin verify" step
- GZIP (using -5 option) during dump step
- Disk contention during the "svnadmin load" step

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

[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

[ANN] SubGit 2.0 Released

[Semyon Vadishev]

Hello all,

Our team is proud to announce SubGit 2.0.0 release! New version is
available for download at SubGit web site at http://subgit.com/

SubGit lets one to set up a bi-directional Git-SVN mirror, and thus it
allows users to choose freely between Subversion and Git version control
systems. SubGit is a perfect tool for those who's going to migrate from
Subversion to Git as well as from Git to SVN.

New version introduces the following major features:

1. Support for remote Subversion repositories;
2. One-shot import from Subversion to Git;
3. Flexible branches and tags layout;
4. Significant performance improvements.

SubGit is a closed source Java application, which is free for use in
Open Source and Academic projects, as well as in any teams with up to 10
committers. Besides, there are no limitations on the time you may
evaluate SubGit in commercial or closed source projects.

Atlassian Stash users can install SVN Mirror Add-on which is based on
SubGit 2.0, so they can manage their Git-SVN mirrors right from Stash
UI:
https://marketplace.atlassian.com/plugins/org.tmatesoft.subgit.stash-svn-importer

For the detailed release notes please refer to
http://subgit.com/documentation/release-notes.html
Documentation on remote Git-SVN mirror mode: http://subgit.com/book-remote/
Documentation on local Git-SVN mirror mode: http://subgit.com/book/
Documentation on one-shot Git-SVN import:
http://subgit.com/book-remote/#import
SubGit Issues Tracker: http://issues.tmatesoft.com/issues/SGT
Follow us at https://twitter.com/subgit and
https://plus.google.com/114128677298030695536

With Best Regards,
Semyon Vadishev on behalf of SubGit Team,
TMate Software,
http://subgit.com/ - Git-SVN Mirror!
http://svnkit.com/ - Java [Sub]Versioning Library!
http://hg4j.com/ - Java Mercurial Library!
http://sqljet.com/ - Java SQLite Library!

Re: Merge order affects final result for repeated added & deleted changes

[Johan Corveleyn]

On Mon, Aug 5, 2013 at 4:20 PM, Fredrik Orderud  wrote:
> There seems to be a problem with the merge logic in SVN when merging
> repeated added & deleted changes out-of-order.
>
> Example activity on branch A:
> r1: A new file is added.
> r2: A line is added
> r3: The line is removed
> r4: The line is re-added
> Later activity on branch B (created from A@r1):
> r5: r2 and r4 are merged in.
> r6: r3 is merged in.
>
> What happens in r5 is that repeated merging of the same change does _not_
> cause duplication or merge conflict. Instead, r4 seems to be ignored. The
> end result after r6 (a complete merge) is that r4 is missing from branch B.
> This is inconsistent with svn:mergeinfo which claims that it has been
> merged. Patches to reproduce are attached.
>
> Could it be possible to make svn merges fail on repeated merges of the same
> change, instead of just ignoring them?
>
> The problem was reproduced using svn 1.8.1 (command-line) client on Win7
> 64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win
> server 2008 R2.
>

I can't offer much real help, but ... I've read something similar before ...

Ah, here it is:

http://svn.haxx.se/dev/archive-2013-04/0205.shtml

a somewhat recent thread on the dev-list. It's quite an interesting
discussion IMO, so at least this gives you some context, and confirms
that this is known behavior.

-- 
Johan

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

[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

[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. 

Cope with IPv6

[Okabayashi, Hirotsugu]

Dear User Support,

Sorry to mistake. This is correct.

Could you tell us the specifications about the authentication with IPv6 ?
These behavior bothers us about IPv6.
 -When connecting to SVN server with IPv6, the client tool(TortoiseSVN:TSVN) 
can't handle the authentication operation.
 -Only with IPv6, the operating system can't handle the authentication. So, 
both authenticated case and not authenticated case,
  TSVN doesn't work. TSVN display the same error messages. 

At first, we thought the problem causes TSVN's specification.
But, the TSVN's user support said the authentication is handled by the SVN's 
API and the serf library.
So, they said the problem relates to SVN's API and the serf library's 
specification.

With IPv6, do SVN's API and the serf library work well when authenticating?

Regards,

> -Original Message-
> From: Okabayashi, Hirotsugu
> Sent: Monday, August 05, 2013 4:18 PM
> To: users@subversion.apache.org
> Cc: SGS/systemtec/CMsupport
> Subject: Cope with IPv6
> 
> Dear User Support,
> 
> Could you tell us the specifications about the authentication with IPv6 ?
> These behavior bothers us about IPv6.
>  -When connecting to SVN server with IPv6, the client
> tool(TortoiseSVN:TSVN) can't handle the authentication operation.
>  -Only with IPv6, the Operating system handle the authentication. So, both
> authenticated case and not authenticated case,
>   TSVN doesn't work. TSVN display the same error message.
> 
> At first, we thought the problem causes TSVN's specification.
> But, the TSVN's user support said the authentication is handled by the SVN's
> API and the serf library.
> So, they said the problem relates to SVN's API and the serf library's
> specification.
> 
> With IPv6, do SVN's API and the serf library work well when authenticating?
> 
> Regards,
> 
> **
> Sony Global Solutions Inc.
> Hirotsugu Okabayashi
> Tel: 03-5479-6566
> Mail:
> **

Re: Cope with IPv6

[Thorsten Schöning]

Guten Tag Okabayashi, Hirotsugu,
am Dienstag, 6. August 2013 um 01:54 schrieben Sie:

> Sorry to mistake. This is correct.

You should really NOT create new threads for an already mentioned
problem without providing any more details. Please stay on one thread
only.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning   E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme  http://www.AM-SoFT.de/

Telefon...05151-  9468- 55
Fax...05151-  9468- 88
Mobil..0178-8 9468- 04

AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow