script or tool to walk back thru 1 file's history diffing..
Would like to write a script to follow the history of a single file, backwards, diffing the file w/it's prior version all the way back to the 1st version. By using 'svn info' to get the last chgd rev, and running 'svn diff -c $lastchgd_rev ...', this seems simple enough if the URL to the file does not change; but if the pathname in svn to the file is renamed there is no choice but to look at 'svn log', right? -- thanks/regards, Tom -- Does such a command line tool already exist?
Re: Disable Keep Alives and/or Pipelining?
Thanks Mark, the Proxy supports it but our Proxy team disables it and prefers it not be enabled. I have been pushing to get KeepAlives enabled and been met with some hesitation, I'm hoping with your answer I'll be able to push them to either enable KeepAlives or remove the Reverse Proxy requirement for this use case. On 3/9/20 8:23 AM, Mark Phippard wrote: On Mon, Mar 9, 2020 at 9:18 AM Kyle Echols <mailto:subvers...@kyleechols.com>> wrote: We run through a reverse proxy for SVN access and that proxy has KeepAlives disabled, as a result, I've been asked if it's possible to disable KeepAlives and/or HTTP Pipelining in the subversion client? For some background, we are getting SSL errors when trying to checkout / update that don't occur going to the server direct (bypassing the proxy) and all we see in the reverse proxy (Apache HTTPd under the covers) logs are: "insecure re-negotiation required, but a pipelined request is present; keep alive disabled" TortoiseSVN returns: Error running context: An error occurred during SSL communication The SVN Server (CollabNET) - Reports a broken pipe, with a "HINT: Stop button pressed in browser?" type message I have always been under the impression the client and server just negotiate the availability of KeepAlive and manage with our without it. That said, since SVN 1.7 the client has needed KeepAlive enabled for performance to be decent: http://subversion.apache.org/docs/release-notes/1.7.html#serf You should get a proxy that supports it -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Subversion reports error.
> % ssh sectio...@section-9.sakura.ne.jp ls /home/section-9/svn/reps README.txt conf db format hooks locks >> and then stops. A prompt is not shown. >> >> Kindest regards, >> Masaru >> This symptom of not getting any prompt back reminds me of a totally non-svn related "bug" but a network error I encountered some time ago. When running a ssh session to a remote computer via en VPN tunnel commands on the remote computer returning a lot of data halted the session after just a couple of lines. i.e. "ls -l" didn't work but "ls" did for the same directory. The problem was that the router where the tunnel ended (or started) on my side had been replaced an the MTU had changed, so network packets to large didn't come through the tunnel.. When the network people corrected the MTU everything worked again. Don't know if that's your problem but I'm telling the story so you can investigate this option. /David a.k.a. Alagazam
Re: Subversion reports error.
On 2012-02-09 00:23, Ryan Schmidt wrote: On Feb 8, 2012, at 15:41, Alagazam.net Subversion wrote: On Feb 7, 2012, at 15:44, Masaru Kitajima wrote: On 2012/02/08, at 6:36, Daniel Shahaf wrote: What is the output of % ssh sectio...@section-9.sakura.ne.jp svnserve -t It is as below: ( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) ) and then stops. A prompt is not shown. This symptom of not getting any prompt back reminds me of a totally non-svn related "bug" but a network error I encountered some time ago. Not seeing a prompt in this case is not a bug; it's expected behavior. svnserve is not an interactive program that has a prompt. It's a Subversion server; the above test demonstrated that svnserve is running correctly and is waiting for a Subversion client to connect to it. Maybe I was reading the threads wrong but my answer about not getting the prompt back was a reply to this part: % sshsectio...@section-9.sakura.ne.jp ls /home/section-9/svn/reps README.txt conf db format hooks locks and then stops. A prompt is not shown. which to me seems like the ssh session is running a normal shell ls command. About the MTU value I'm really don't know as it was in the VPN routers which I don't manage, but it's normally 1500 so I guess the change was to 1490 or something to account for the VPN headers. /David
Re: Problem with Python bindings to SVN 1.7.4 on Windows
On 2012-03-21 18:15, Brian Neal wrote: On Wed, Mar 21, 2012 at 12:10 PM, Cooke, Mark wrote: On Wed, Mar 21, 2012 at 11:12 AM, Brian Neal wrote: I have solved my problem by copying libeay32.dll and ssleay32.dll from the Subversion\bin folder to C:\Python27\Lib\site-packages\libsvn folder. I got this tip via a google search on the Trac users list. I don't understand this, but thought I would follow-up here on this list in case it helps other poor dopes who have to run on Windows. -BN Thinking about this, I have the subversion bin folder in my path, I suspect that it is not in yours? I assume therefore you probably use TortoiseSVN (and why not) which does not (AFAIK) need svn in the path so does not add it... ~ mark c I'm doing all this work on the server side. Yes, C:\Program Files\Subversion\bin is on the path. It is needed for Apache to find the SVN binaries. It is strange that I also need to copy those 2 DLL's to the Python bindings folder. Thanks, BN Do you have another libeay32.dll and ssleay32.dll in some other folder that is before Subversion\bin in your path ? If that's the case and these are older versions there might be trouble. /David a.k.a. Alagazam
Re: Problem with Python bindings to SVN 1.7.4 on Windows
On 2012-03-21 20:14, Brian Neal wrote: On Wed, Mar 21, 2012 at 1:41 PM, Alagazam.net Subversion wrote: Do you have another libeay32.dll and ssleay32.dll in some other folder that is before Subversion\bin in your path ? If that's the case and these are older versions there might be trouble. /David a.k.a. Alagazam Why yes, those DLL's do exist in an earlier folder on the path! Is there anything that can be done to avoid a problem like that in the future? Perhaps a note in the readme? I have noticed that Bitnami and Collabnet dump all the SVN and Python binding DLL's into the same folder. I'm not a windows / dll expert so I don't know if that is a good solution or not. Thanks for the help. And thanks very much for making those Windows binaries available. -BN That is a good solution. You can always have the habit of downloading the zip file with the Subversion binaries (svn-win32-1.7.4.zip) and extract it (or at least the dll:s) in the same folder where you have the Python bindings. /David a.k.a. Alagazam
Re: Subversion 1.7.5 compatibility question
On 2012-05-18 15:23, Edisandro Lima wrote: Hello, I have downloaded the Windows version (.msi installer) maintained by David Darj (http://alagazam.net/) and I would like to know whether or not this new 1.7.5 version is compatible with Apache 2.4 VC10 builds downloaded from ApacheLaunge.com I've been using Subversion 1.7.4 without problems on Apache 2.2, but it did not work on Apache 2.4. So this new version fixes this issue ? Best Regards, Edisandro. Hi My release is NOT compatible with Apache httpd 2.4. I did a test doing my build against Apache httpd 2.4 including building httpd itself. It's not very well tested (all svn tests passes though), and I don't know if it's compatible with ApacheLaunge https as I use VC6 (yes it's ancient, I know ;-) but if you want I can give you a link to test it. Regards David Darj a.k.a. Alagazam
Re: Missing dll files
On 2012-10-14 10:20, Steven Venter wrote: Hi Windows 7 64 XAMPP 1.8.0 WebSVN 2.3.3 SVN Server 1.7.6 (http://alagazam.net/) I installed WebSVN 2.3.3 but had a number of issues with missing dll files. I was able to resolve most of these issues except for MSVCR80.dll. I download this dll and installed it to the SVN bin directory. Now I get a runtime error R6035 when ever I select one of the navigation options in WebSVN. I can dismiss the dialog box and WebSVN seems to continue working correctly. This dll seems to be for applications build with VS 2005 and according to my research is no longer required for the windows operating systems. If the MSCVR80.dll file is not included, the Apache server just dies. Has anyone had simmilar issues and if so how did they resolve them? Thanks Steven This SVN package is built using VC-6 so it should not need this DLL. It uses MSVCRT.dll from that. Regards David a.k.a. Alagazam
Re: windows binaries with xampp
On 2013-03-21 21:01, Andrew Peterson wrote: Has anyone successfully used xampp with the binaries from: Win32Svn <http://sourceforge.net/projects/win32svn/> (32-bit client, server and bindings, MSI and ZIPs; maintained by David Darj <http://alagazam.net/>) I've tried a bunch of different configurations, but every time I tried to load the mod_dav_svn.so and the mod_authz_svn.so, apache just crashes and tells me it can't load the module. Thanks, Andrew Hi I just tested xampp 1.7.4 with Subversion 1.7.8 (Apache 2.2 version) and it worked. Also got xampp 1.8.1 working with Subversion 1.7.8 (Apache 2.4 version). I was unsure that the 1.8.1 should work since it said it was compiled with vc9 (Visual studio 2008) and I use vc6 (Visual Studio 6) for the subversion build. But it worked. All i did was unpacking the Subversion zip file to C:\Subversion. Creating a repository with "C:\Subversion\bin\svnadmin create C:\Svn.repo" Adding the following to C:\xampp\Apache\conf\httd.conf LoadModule dav_module modules/mod_dav.so LoadModule dav_svn_module C:/Subversion/bin/mod_dav_svn.so DAV svn SVNPath C:/Svn.repo Then restarting Apache. Didn't even have to add subversion bin folder to the system path variable. Directing the webbrowser to http://localhost/svn then showed the subversion repository. My setup is a quite clean Windows 7 XP mode virtual machine. regards David a.k.a. Alagazam
Re: questions about subversion secondary development
On 2013-04-29 10:36, Cooke, Mark wrote:
-Original Message-
From: Edwin Cheung [mailto:edoka...@gmail.com]
Sent: 27 April 2013 07:55
To: users@subversion.apache.org
Subject: questions about subversion secondary development
Dear sir or madam:
When I use the binary packages ( Win32Svn
<http://sourceforge.net/projects/win32svn/> ,
svn-win32-1.6.21_dev.zip) to run the example code named
"minimal_client.c"(located in the directory of
"subversion-1.6.21\tools\examples"), I get an access
violation on calling "svn_cmdline_init("minimal_client", stderr)".
My build tool is Visual Studio 2008 on Windows 7(or
Windows xp).How to solve this problem? Please help me.
Thanks a lot and look forward to hearing from you soon.
Best Regards,
Cunchao Cheung
In the absence of the maintainer answering, I believe that the sourceforge
win32svn package you are using is built using Vicual C++ 6 (e.g. for
compatability with the VC6 binaries of httpd that apache.org used to host).
If you want to use it with Visual Studio 2008 you will need to find a different
binary, built using VS2008. Both CollabNet and WANdisco (amongst others) also
provide binaries, try some of those...
Cheers,
~ mark c
Hi all
That's correct Mark (thanks for answering in my absence).
My build is using VC++6 and I suppose that's the reason it doesn't work.
Although I have tried using the Apache modules in my build on in newer
versions of xampp (which includes httpd) that is build using newer
compilers (VC9/VS2008) and it's working. But I think it might be that
the apache modules have nice clean interfaces.
/David a.k.a. Alagazam
Re: Win32Svn Binaries - wspiapi.h include
Hi Kai! For some reason I've patched apr.h with this #include to get it build, but I don't remember why. After a quick look at the file (wspiapi.h) i suppose it is to get the definition of "getaddrinfo" function, which is used by apr. Maybe I should have done this patch in some cpp file instead. If you get it build without it I think it's safe. Best regard David a.k.a. Alagazam Maintainer of Win32Svn binaries On 2013-05-27 11:33, kai-uwe.schie...@hydrometer.de wrote: Hi folks! Please add me to the CC list on this topic, I am not subscribed. I try to implement the svn lib in my own software using the Win32Svn binary package (Version 1.7.9 - apache22). My compiler is the Visual C++ 6.0, the operating system is Windows XP. When I try to compile there occurs an error "Cannot find include file 'wspiapi.h' " in the apr.h. I think this files is provided by the Windows SDK 7.0A from Microsotft. But I don't know, why I need this for Windows XP. When I delete the include lines, the project can be compiled without error. What do you guess? How could I handle this problem? Thank you all , Kai. Bitte überlegen Sie, ob Sie diese Nachricht wirklich ausdrucken müssen/ before printing, think about environmental responsibility. Hydrometer GmbH, Industriestraße 13, 91522 Ansbach Telefon + 49 981 1806 0, Telefax +49 981 1806 615 Sitz der Gesellschaft: Ansbach, Registergericht: Ansbach HRB 69 Geschäftsführer: Frank Gutzeit (Sprecher), Dr.-Ing. Robert Westphal, Thomas Gastner, Adam Mechel Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Informieren Sie uns bitte, wenn Sie diese E-Mail fälschlicherweise erhalten haben. Bitte löschen Sie in diesem Fall die Nachricht. Jede unerlaubte Form der Reproduktion, Bekanntgabe, Änderung, Verteilung und/oder Publikation dieser E-Mail ist strengstens untersagt. The contents of the above mentioned e-mail is not legally binding. This e-mail contains confidential and/or legally protected information. Please inform us if you have received this e-mail by mistake and delete it in such a case. Each unauthorized reproduction, disclosure, alteration, distribution and/or publication of this e-mail is strictly prohibited.
Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi everyone. I got curious to see if they are using my VC6 build of Subversio a.k.a. Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for Apache 2.4.x that's is included in the Bitnami Redmine Windows installer. Building Win32SVN and testing is done against a httpd built at the same time (or sometimes a previous build) with the same compiler VC6. I haven't tested Win32SVN with httpd built using more modern VC++. It seems like Bitnami's httpd it built with VS2010 (at least as Dependency Walker shows). If time permit I can try to run the svn testsuite with these installation. Best regards David a.k.a. Alagazam Maintainer of Win32SVN On 2014-02-03 17:31, Steve Davis wrote: Ah - with a bit of digging around the binary libraries, I can see that it looks like subversion was still built using vc6, and apache using a mix of 2008 and/or 2010. This being the case, I'd say that this is a prime candidate for what's causing the problem (based upon the comments in the second link)... So it's not a problem with Redmine or with apache - but it >is< a problem when the binaries used aren't built using the same version of compiler (this is all theory at the moment of course) -Original Message- From: Steve Davis Sent: 03 February 2014 15:35 To: 'Philip Martin' Cc: users@subversion.apache.org <mailto:users@subversion.apache.org> Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time? Thanks for your time on this Regards - Steve -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 03 February 2014 15:34 To: Steve Davis Cc: users@subversion.apache.org <mailto:users@subversion.apache.org> Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Steve Davis mailto:steve.da...@uk.rapp.com>> writes: > Response: > > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL > svn: E200035: Additional errors: > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL I can generate this error with the 1.8 client by patching mod_dav_svn to return 400: Index: sw/subversion/src/subversion/mod_dav_svn/lock.c ======= --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833) +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy) @@ -670,7 +670,7 @@ DAV_ERR_LOCK_SAVE_LOCK, "Path is not accessible."); - if (lock->next) + /*if (lock->next)*/ return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST, DAV_ERR_LOCK_SAVE_LOCK, "Tried to attach multiple locks to a resource."); A trunk client gives a better error: svn: warning: W160040: No lock on path 'f' (400 Bad Request) The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838 a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320 somebody else reports a similar incompatibility which was solved by using different binaries. Do you know how your Apache and Subversion binaries were produced? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personn
