svn diff property order

[Dennis Hendriks]

Hello all,

When doing an 'svn diff', the output includes the actual diff, but also the 
diff of the properties of the files. However, the properties don't always 
appear in the same order. This makes it difficult to use standard 'diff' 
tools to compare patches.


I had noticed this before on the order of the files in 'svn diff', but that 
seems to have been resolved by upgrading SVN 1.6 to 1.8. I currently use 
the following Subversion version:


$ svn --version
svn, version 1.8.8 (r1568071)
   compiled Feb 21 2014, 09:06:41 on x86_64-unknown-linux-gnu

I did some searches, and found bug 4134. It seems 'svnadmin dump', 'svn 
proplist', and 'svn propget' are/were affected as well:


http://subversion.tigris.org/issues/show_bug.cgi?id=4134

To me, it would seem like a good idea to have a reproducible (sorted?) 
order of properties. What do you all think?


Best regards,
Dennis

Re: Upgrade from 1.7.5 to 1.8.8 mod_dav_svn breaks

[Ryan Schmidt]

On Apr 22, 2014, at 17:00, Tom Kielty wrote:

> We have been using SVN with WebSVN for 7 years now. It is a non-SSL, hosted 
> on a Windows 2008 R2 server behind Apache 2.2.
> 
> Recently we looked into upgrading from SVN 1.7.5 with WebSVN 2.3.3 to SVN 
> 1.8.8 and the same WebSVN 2.3.3.
> 
> The SVN upgrade worked with no issues.
> I ran the svnadmin upgrade  step with no issues.
> 
> However, when I replaced the mod_dav_svn.so and mod_auth_sv.so with the 
> latest versions my WebSVN stopped working. The clients work fine for 
> accessing the server. And the direct URL http:///RND work correctly 
> as well.
> 
> However, WebSVN does not. If I do not replace the modules WebSVN continues to 
> work just fine. When I do replace them I get a "Not Found" error when going 
> to http:///websvn/index.php. If I just go to http:///websvn I 
> get my main repo listing. Before I would get the files under the websvn 
> folder in apache.
> 
> I figure I am missing something that changed form 1.7 to 1.8 but I can't 
> pinpoint it. Below are my  definitions from my http.conf file.
> 
> 
>   DAV svn
>   SVNPath D:/Repositories/RND
>   AuthName "SVN Server"
>   AuthType SSPI
>   SSPIAuth On
>   SSPIAuthoritative On
>   SSPIDomain 
>   SSPIOfferBasic on #let non-IE clients authenticate
>   SSPIOmitDomain On
>   AuthzSVNAccessFile "D:/Repositories/RND/svnaccess.conf"
>   Require valid-user
> 
> 
> 
>   SVNPath D:\Repositories\RND
>   AuthType SSPI
>   SSPIAuth On
>   SSPIAuthoritative On
>   SSPIDomain 
>   SSPIOfferBasic On
>   SSPIOmitDomain On
>   Require valid-user
> 
> 
> Any suggestions would be appreciated.

You shouldn’t be setting SVNPath within the “” block, should 
you? That only belongs in the “” block.

Consult your Apache error log for information on why an error occurred.

Re: Extra blank line when using command line editor for commit message

[Ryan Schmidt]

On Apr 22, 2014, at 22:22, Justin Mrkva wrote:

> I see, that’s good to know. I’ll definitely set it up, it does make sense to 
> strip whitespace. Not sure why that isn’t done by default. :)
> 
> Now I just have to figure out if a dump/load will apply the hooks to to clean 
> up old log messages that have trailing whitespace. Not a big deal in the 
> scheme of things though.

dump/load uses svnadmin and does not invoke hook scripts.

But there’s no need to dump and load to correct revision properties of past 
revisions. Just install a pre-commit-hook script allowing modification of those 
properties, then run log-police.py with the --all-revs option, as the usage 
message shows:


USAGE: log-police.py [-t TXN_NAME | -r REV_NUM | --all-revs] REPOS

Ensure that log messages end with exactly one newline and no other
whitespace characters.  Use as a pre-commit hook by passing '-t TXN_NAME';
fix up a single revision by passing '-r REV_NUM'; fix up all revisions by
passing '--all-revs'.  (When used as a pre-commit hook, may modify the
svn:log property on the txn.)

Re: Extra blank line when using command line editor for commit message

[Ryan Schmidt]

On Apr 23, 2014, at 04:37, Ryan Schmidt wrote:

> Just install a pre-commit-hook script allowing modification of those 
> properties

er, make that a pre-revprop-change hook script.

RE: TortoiseSVN, OPTIONS request on 'foo' failed: 501 Not Implemented

[Bert Huijben]

> -Original Message-
> From: Carl Brewer [mailto:c...@aboc.com.au]
> Sent: woensdag 23 april 2014 06:57
> To: users@subversion.apache.org
> Subject: TortoiseSVN, OPTIONS request on 'foo' failed: 501 Not Implemented
> 
> 
> G'day,
> I have a SVN repository that runs through apache (2.4), that works fine
> 99% of the time, but I am seeing the error
> 
> OPTIONS request on '/svn/hcc_wko' failed: 501 Not Implemented
> 
> only on one windows 7 64 bit PC.  This happens if I try to checkout, or
> if I grab a copy of a working checkout from another win7 64 bit PC and
> then try an update.  Tortoise is the latest version.  SVN is 1.8.8 on a
> NetBSD server running amd64 from NetBSD's pkgsrc.
> 
> The server logs show :
> 
> 161.43.212.211 - - [23/Apr/2014:14:55:22 +1000] "OPTIONS /svn/hcc_wko
> HTTP/1.1" 401 381
> 161.43.212.211 - glenn [23/Apr/2014:14:55:41 +1000] "OPTIONS
> /svn/hcc_wko HTTP/1.1" 200 191
> 161.43.212.211 - - [23/Apr/2014:14:55:42 +1000] "OPTIONS /svn/hcc_wko
> HTTP/1.1" 401 381
> 161.43.212.211 - glenn [23/Apr/2014:14:55:42 +1000] "OPTIONS
> /svn/hcc_wko HTTP/1.1" 200 191
> 161.43.212.211 - - [23/Apr/2014:14:55:43 +1000] "OPTIONS /svn/hcc_wko
> HTTP/1.1" 401 381
> 161.43.212.211 - glenn [23/Apr/2014:14:55:44 +1000] "OPTIONS
> /svn/hcc_wko HTTP/1.1" 200 191
> 

The server didn't sent the error 501 if this is really all the log output
there is. 

> 
> Any hints?

So I would recommend checking for proxy servers, firewalls and/or virus
scanners that change the behavior of web requests.

Bert

> 
> Carl

RE: Subversion Windows Performance compared to Linux

[Grierson, David]

Latency Numbers Every Programmer Should Know:

https://gist.github.com/jboner/2841832

Always useful to have in mind when considering your benchmarking environment.
--
David Grierson – SDLC Tools Specialist 
Sky Broadcasting - Customer Business Systems - SDLC Tools
Tel: +44 1506 325100 / Email: david.grier...@bskyb.com / Chatter: CBS SDLC Tools
Watermark Building, Alba Campus, Livingston, EH54 7HH


> -Original Message-
> From: Nico Kadel-Garcia [mailto:nka...@gmail.com]
> Sent: 23 April 2014 06:21
> To: Mark Phippard
> Cc: Florian Ludwig; users@subversion.apache.org
> Subject: Re: Subversion Windows Performance compared to Linux
> 
> On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard  wrote:
> > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
> 
> > wrote:
> >
> >>
> >> this topic was raised several times in the past - the answers range
> from
> >> "will be better/solved in the next version 1.7" or "it is due to ntfs
> vs
> >> ext3/4" or it's the AV, network setup or the Windows file indexing
> service.
> >> After disabling all those and running a test checkout on Linux and
> Windows
> >> on the same machine I still get a result of Linux being 7.3x times
> faster.
> >> Any ideas why?
> >
> >
> > There are probably some good discussions about this in the archives
> during
> > the run-up to 1.7 but my memories are fading.  I do not think anyone
> ever
> > said that the difference would be "solved" but more that the
> architectural
> > changes in 1.7 were going to close the performance gap on Windows when
> > compared to SVN 1.5/1.6 on Linux.  There were a couple of big
> performance
> > fixes backported to some the later 1.6.x releases so the "win" in 1.7 is
> not
> > as great when compared with 1.6.latest as it is with 1.6.0.
> 
> I remember this. The deadly operation was the initial checkout on
> network based file systems, especially CIFS on the Windows boxes. The
> few servers that ran NFS acted much more like Linux hosts, or like
> Linux hosts usin gNFS. A number of changes in Subversion, over time,
> reduced the perfidious chattiness that hampered CIFS baed checkouts,
> and all Windows users with network mounted working copies became
> *much* happier.
> 
> Let's do be careful to draw distinctions between local file systems,
> like NTFS and ext4, and network file systems like CIFS and NFS. I'm
> afraid it's common to handwave those away as not making a difference,
> and they really do.
> 
> Nico Kadel-Garcia


Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and 
Sky International AG and are used under licence. British Sky Broadcasting 
Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration 
No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) 
are direct or indirect subsidiaries of British Sky Broadcasting Group plc 
(Registration No. 2247735). All of the companies mentioned in this paragraph 
are incorporated in England and Wales and share the same registered office at 
Grant Way, Isleworth, Middlesex TW7 5QD.

SVN Show Logs with no users in Tortoise “Show log” for properties change

[nisha]

We have noticed that sometimes we are missing user ID (“Author” column) 
when we use the Tortoise “Show log”. This happens when we change some 
properties on files or folders and we commit them. Is it possible to 
correct it .

Help is much appreciated.
Thanks.

Re: Upgrade from 1.7.5 to 1.8.8 mod_dav_svn breaks

[Tom Kielty]

Ryan,

Thanks for catching that. I have had that in their for 7 years with no
issues.

Tom


On Wed, Apr 23, 2014 at 4:32 AM, Ryan Schmidt <
subversion-2...@ryandesign.com> wrote:

>
> On Apr 22, 2014, at 17:00, Tom Kielty wrote:
>
> > We have been using SVN with WebSVN for 7 years now. It is a non-SSL,
> hosted on a Windows 2008 R2 server behind Apache 2.2.
> >
> > Recently we looked into upgrading from SVN 1.7.5 with WebSVN 2.3.3 to
> SVN 1.8.8 and the same WebSVN 2.3.3.
> >
> > The SVN upgrade worked with no issues.
> > I ran the svnadmin upgrade  step with no issues.
> >
> > However, when I replaced the mod_dav_svn.so and mod_auth_sv.so with the
> latest versions my WebSVN stopped working. The clients work fine for
> accessing the server. And the direct URL http:///RND work
> correctly as well.
> >
> > However, WebSVN does not. If I do not replace the modules WebSVN
> continues to work just fine. When I do replace them I get a "Not Found"
> error when going to http:///websvn/index.php. If I just go to
> http:///websvn I get my main repo listing. Before I would get the
> files under the websvn folder in apache.
> >
> > I figure I am missing something that changed form 1.7 to 1.8 but I can't
> pinpoint it. Below are my  definitions from my http.conf file.
> >
> > 
> >   DAV svn
> >   SVNPath D:/Repositories/RND
> >   AuthName "SVN Server"
> >   AuthType SSPI
> >   SSPIAuth On
> >   SSPIAuthoritative On
> >   SSPIDomain 
> >   SSPIOfferBasic on #let non-IE clients authenticate
> >   SSPIOmitDomain On
> >   AuthzSVNAccessFile "D:/Repositories/RND/svnaccess.conf"
> >   Require valid-user
> > 
> >
> > 
> >   SVNPath D:\Repositories\RND
> >   AuthType SSPI
> >   SSPIAuth On
> >   SSPIAuthoritative On
> >   SSPIDomain 
> >   SSPIOfferBasic On
> >   SSPIOmitDomain On
> >   Require valid-user
> > 
> >
> > Any suggestions would be appreciated.
>
> You shouldn’t be setting SVNPath within the “” block,
> should you? That only belongs in the “” block.
>
> Consult your Apache error log for information on why an error occurred.
>
>

Re: Subversion 1.8 httpd.exe taking 100% CPU

[mark_w]

On Wed, Dec 11, 2013 at 12:28 AM, Ben Reser  wrote:

> I came to the conclusion that there was an LDAP problem as well.
>
> Things that would be interesting to know is if the httpd version changed
> along
> with the Subversion version or if httpd was left alone and only Subversion
> was
> updated.
>

We have experienced the 100% CPU consumption for some time now as well. We
are using mpm_winnit and LDAP. I did manage to get a stack trace of the
thread (085:a1c) running in a hard loop consuming 100% of 1 CPU on a 4 CPU
machine. Here is our version info and the trace:

[Thu Apr 17 10:27:28.528141 2014] [mpm_winnt:notice] [pid 3844:tid 436]
AH00455: Apache/2.4.7 (Win64) SVN/1.8.8 OpenSSL/1.0.1f configured --
resuming normal operations
[Thu Apr 17 10:27:28.528141 2014] [mpm_winnt:notice] [pid 3844:tid 436]
AH00456: Server built: Feb 14 2014 06:04:26

085:a1c
libaprutil_1!apr_reslist_cleanup_order_set+0xc2
libaprutil_1!apr_rmm_calloc+0x84
mod_ldap+0x61d9
mod_ldap+0x6907
mod_ldap+0x39f2
mod_authnz_ldap+0x1ae3
mod_auth_basic+0x17f7
libhttpd!ap_run_check_user_id+0x35
libhttpd!ap_process_request_internal+0x3c4
libhttpd!ap_die+0x4bf
libhttpd!ap_die+0x577
libhttpd!ap_psignature+0x1865
libhttpd!ap_run_process_connection+0x35
libhttpd!ap_regkey_value_remove+0x1603
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

4 other threads had similar stack traces and appeared to be looping as well
though those threads appeared to be running between 30% to 50%. In aggregate
all of the threads of the httpd child process consumed 99% to 100% of our 4
CPU server. My conjecture is that there is some thread safety issue (please
excuse my lack of proper thread terminology) that is causing the looping
when multiple threads enter the same LDAP code shown in the traces. Once
that happens the thread that passes connections into the worker threads
can't do and so that thread eventually uses up all the worker threads but is
unable to actually pass the work off to the workers. Most of the worker
threads stack traces show them blocked on "ntdll!ZwRemoveIoCompletion+0xa"
which I think is the normal wait state. Here's a two of the other four
suspect stack traces which are all similar.

087:1264
libaprutil_1!apr_reslist_cleanup_order_set+0xc2
libaprutil_1!apr_rmm_calloc+0x84
mod_ldap+0x624b
mod_ldap+0x5fc6
mod_ldap+0x69c1
mod_ldap+0x39f2
mod_authnz_ldap+0x1ae3
mod_auth_basic+0x17f7
libhttpd!ap_run_check_user_id+0x35
libhttpd!ap_process_request_internal+0x3c4
libhttpd!ap_die+0x4bf
libhttpd!ap_die+0x577
libhttpd!ap_psignature+0x1865
libhttpd!ap_run_process_connection+0x35
libhttpd!ap_regkey_value_remove+0x1603
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

090:7b0
libaprutil_1!apr_reslist_cleanup_order_set+0xc6
libaprutil_1!apr_rmm_calloc+0x84
mod_ldap+0x61d9
mod_ldap+0x6907
mod_ldap+0x39f2
mod_authnz_ldap+0x1ae3
mod_auth_basic+0x17f7
libhttpd!ap_run_check_user_id+0x35
libhttpd!ap_process_request_internal+0x3c4
libhttpd!ap_die+0x4bf
libhttpd!ap_die+0x577
libhttpd!ap_psignature+0x1865
libhttpd!ap_run_process_connection+0x35
libhttpd!ap_regkey_value_remove+0x1603
kernel32!BaseThreadInitThunk+0xd
ntdll!RtlUserThreadStart+0x1d

We upgraded to the latest version of Subversion on Monday and the problem
reoccurred early this morning though we were not able to get a process dump.

[Wed Apr 23 04:15:17.065606 2014] [mpm_winnt:notice] [pid 1728:tid 436]
AH00455: Apache/2.4.9 (Win64) SVN/1.8.8 OpenSSL/1.0.1g configured --
resuming normal operations
[Wed Apr 23 04:15:17.065606 2014] [mpm_winnt:notice] [pid 1728:tid 436]
AH00456: Server built: Apr  8 2014 03:06:16

Any advice or suggestions for alleviating this chronic issue would be
appreciated. Let me know if anyone wants additional information or
clarification.

mark w
 





--
View this message in context: 
http://subversion.1072662.n5.nabble.com/Subversion-1-8-httpd-exe-taking-100-CPU-tp182657p188345.html
Sent from the Subversion Users mailing list archive at Nabble.com.

File externals into another external

[Benjamin Fritz]

I had a problem at work, where somebody created a tag for a library,
and then deleted a bunch of files I needed from that tag. When I
updated my svn:externals definition in my application to pull in the
new library version, those files went away. I tried to fix it in my
application, by creating file externals for those files, pointing to a
previous version, but placed into the same location they would have
been had the person not deleted them.

I know it is not possible to create a file external from a different
repository. But I expected this to work, because it is from the same
repository, and the directory already exists.

Is this limitation intentional, explained by this statement from
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html ?

"While directory externals can place the external directory at any
depth, and any missing intermediate directories will be created, file
externals must be placed into a working copy that is already checked
out."

Re: Upgrade from 1.7.5 to 1.8.8 mod_dav_svn breaks

[Ryan Schmidt]

On Apr 23, 2014, at 08:45, Tom Kielty wrote:

> On Wed, Apr 23, 2014 at 4:32 AM, Ryan Schmidt wrote:
> 
>> You shouldn’t be setting SVNPath within the “” block, 
>> should you? That only belongs in the “” block.
> 
> Thanks for catching that. I have had that in their for 7 years with no issues.

Did that fix it? I was only guessing, but it was the one directive that looked 
out of place to me.

Re: Upgrade from 1.7.5 to 1.8.8 mod_dav_svn breaks

[Tom Kielty]

Yes it did. Thanks.


Ryan Schmidt  wrote:

>
>On Apr 23, 2014, at 08:45, Tom Kielty wrote:
>
>> On Wed, Apr 23, 2014 at 4:32 AM, Ryan Schmidt wrote:
>> 
>>> You shouldn’t be setting SVNPath within the “” block, 
>>> should you? That only belongs in the “” block.
>> 
>> Thanks for catching that. I have had that in their for 7 years with no 
>> issues.
>
>Did that fix it? I was only guessing, but it was the one directive that looked 
>out of place to me.
>