Running Bugzilla and SVN in same Server
I have SVN running in my machine which has IP address 192.168.0.xx ...I also have installed Bugzilla on same machinehowever if i type 192.168.0.xx/bugzilla..only login prompt for svn is appearing...How can i use my machine's IP address for both bugzilla and svn?
Re: Running Bugzilla and SVN in same Server
On Mon, Nov 19, 2012 at 4:27 PM, Ratheesh Sahayaraj < aegan.rathe...@gmail.com> wrote: > I have SVN running in my machine which has IP address > 192.168.0.xx ...I also have installed Bugzilla on same > machinehowever if i type 192.168.0.xx/bugzilla..only login > prompt for svn is appearing...How can i use my machine's IP > address for both bugzilla and svn? > you need to fix your Apache configuration for same, can you share your current config ? -- Vishwajeet Singh +91-9657702154 | dextrou...@gmail.com | http://bootstraptoday.com Twitter: http://twitter.com/vishwajeets | LinkedIn: http://www.linkedin.com/in/singhvishwajeet
Re: Running Bugzilla and SVN in same Server
Guten Tag Ratheesh Sahayaraj, am Montag, 19. November 2012 um 11:57 schrieben Sie: > How can i use my machine's IP > address for both bugzilla and svn? Your webserver is not configured properly, you may post the interesting parts of your configuration and one can have a look. 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: Running Bugzilla and SVN in same Server
# # This is the main Apache server configuration file. It contains the # configuration directives that give the server its instructions. # See http://httpd.apache.org/docs/2.2/> for detailed information. # In particular, see # http://httpd.apache.org/docs/2.2/mod/directives.html> # for a discussion of each configuration directive. # # # Do NOT simply read the instructions in here without understanding # what they do. They're here only as hints or reminders. If you are unsure # consult the online docs. You have been warned. # # The configuration directives are grouped into three basic sections: # 1. Directives that control the operation of the Apache server process as a # whole (the 'global environment'). # 2. Directives that define the parameters of the 'main' or 'default' server, # which responds to requests that aren't handled by a virtual host. # These directives also provide default values for the settings # of all virtual hosts. # 3. Settings for virtual hosts, which allow Web requests to be sent to # different IP addresses or hostnames and have them handled by the # same Apache server process. # # Configuration and logfile names: If the filenames you specify for many # of the server's control files begin with "/" (or "drive:/" for Win32), the # server will use that explicit path. If the filenames do *not* begin # with "/", the value of ServerRoot is prepended -- so "logs/foo.log" # with ServerRoot set to "/etc/httpd" will be interpreted by the # server as "/etc/httpd/logs/foo.log". # ### Section 1: Global Environment # # The directives in this section affect the overall operation of Apache, # such as the number of concurrent requests it can handle or where it # can find its configuration files. # # # Don't give away too much information about all the subcomponents # we are running. Comment out this line if you don't mind remote sites # finding out what major optional modules you are running ServerTokens OS # # ServerRoot: The top of the directory tree under which the server's # configuration, error, and log files are kept. # # NOTE! If you intend to place this on an NFS (or otherwise network) # mounted filesystem then please read the LockFile documentation # (available at http://httpd.apache.org/docs/2.2/mod/ mpm_common.html#lockfile>); # you will save yourself a lot of trouble. # # Do NOT add a slash at the end of the directory path. # ServerRoot "/etc/httpd" # # PidFile: The file in which the server should record its process # identification number when it starts. # PidFile run/httpd.pid # # Timeout: The number of seconds before receives and sends time out. # Timeout 120 # # KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive Off # # MaxKeepAliveRequests: The maximum number of requests to allow # during a persistent connection. Set to 0 to allow an unlimited amount. # We recommend you leave this number high, for maximum performance. # MaxKeepAliveRequests 100 # # KeepAliveTimeout: Number of seconds to wait for the next request from the # same client on the same connection. # KeepAliveTimeout 15 ## ## Server-Pool Size Regulation (MPM specific) ## # prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # ServerLimit: maximum value for MaxClients for the lifetime of the server # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 # worker MPM # StartServers: initial number of server processes to start # MaxClients: maximum number of simultaneous client connections # MinSpareThreads: minimum number of worker threads which are kept spare # MaxSpareThreads: maximum number of worker threads which are kept spare # ThreadsPerChild: constant number of worker threads in each server process # MaxRequestsPerChild: maximum number of requests a server process serves StartServers 2 MaxClients 150 MinSpareThreads 25 MaxSpareThreads 75 ThreadsPerChild 25 MaxRequestsPerChild 0 # # Listen: Allows you to bind Apache to specific IP addresses and/or # ports, in addition to the default. See also the # directive. # # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 Listen 80 # # Dynamic Shared Object (DSO) Support # # To be able to use the functionality of a module which was built as a DSO you # have to place corresponding `LoadModule' lines at this location so the # directives contained in it are actually available _before_ they are used. #
Re: Running Bugzilla and SVN in same Server
Guten Tag Ratheesh Sahayaraj,
am Montag, 19. November 2012 um 12:59 schrieben Sie:
>
> ServerAdmin webmas...@dummy-host.example.com
> DocumentRoot /var/www/html/websvn
> ServerName svn
> ErrorLog logs/websvn-error_log
> CustomLog logs/websvn-access_log common
>
> Options +FollowSymLinks
> AllowOverride None
> order allow,deny
> allow from all
> AuthType Basic
> AuthName "Subversion Repository"
> Require valid-user
> AuthUserFile /svn/conf/svn-auth-file
>
> php_flag magic_quotes_gpc Off
> php_flag track_vars On
>
>
>
You should read the docs on what a virtual host is and how it works,
afterwards you can configure the same for Bugzilla and access both
applications using proper names as you already configured "svn" for
WebSVN.
> PerlSwitches -I/var/www/html/bugzilla -I/var/www/html/bugzilla/lib -w -
> T
> PerlConfigureRequire /var/www/html/bugzilla/mod_perl.pl
You shouldn't need the I-switch and those two lines assume that
nothing else is running in your httpd, you can't have Bugzilla and
Subversion in parallel this way. You need virtual hosts, read about
them. Below is an exmaple configuration I use, I don't use with
commented mod_pelr.pl because I don't use it currently.
ServerAdmin bugzi...@example.org
ServerName bugzilla.example.org
DocumentRoot /usr/local/apache/htdocs/bugzilla
AddHandler cgi-script .cgi
AddHandler imap-file map
DirectoryIndex index.cgi
Options Indexes FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order allow,deny
allow from all
ErrorLog ${APACHE_LOG_DIR}/bugzilla/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/bugzilla/access.log combined
#PerlSwitches -w -T
#PerlConfigRequire /usr/local/apache/htdocs/bugzilla/mod_perl.pl
PerlOptions +Parent
http://www.bugzilla.org/docs/4.2/en/html/configuration.html
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: Running Bugzilla and SVN in same Server
On Mon, Nov 19, 2012 at 7:21 AM, Thorsten Schöning wrote: > Guten Tag Ratheesh Sahayaraj, > am Montag, 19. November 2012 um 12:59 schrieben Sie: > >> >> ServerAdmin webmas...@dummy-host.example.com >> DocumentRoot /var/www/html/websvn >> ServerName svn >> ErrorLog logs/websvn-error_log >> CustomLog logs/websvn-access_log common >> >> Options +FollowSymLinks >> AllowOverride None >> order allow,deny >> allow from all >> AuthType Basic >> AuthName "Subversion Repository" >> Require valid-user >> AuthUserFile /svn/conf/svn-auth-file >> >> php_flag magic_quotes_gpc Off >> php_flag track_vars On >> >> >> > > You should read the docs on what a virtual host is and how it works, > afterwards you can configure the same for Bugzilla and access both > applications using proper names as you already configured "svn" for > WebSVN. > >> PerlSwitches -I/var/www/html/bugzilla -I/var/www/html/bugzilla/lib -w - >> T >> PerlConfigureRequire /var/www/html/bugzilla/mod_perl.pl > > You shouldn't need the I-switch and those two lines assume that > nothing else is running in your httpd, you can't have Bugzilla and > Subversion in parallel this way. You need virtual hosts, read about > them. Below is an exmaple configuration I use, I don't use with > commented mod_pelr.pl because I don't use it currently. Note that hostname based virtual hosts are one of the irksome poltergeists of secure computing. The big part of the problem is that SSL keys are tied to IP addresses, and you can't use different keys for different virtual hosts on the same IP address. The other problem is that for most configurations, you wind up having to use the fully qualified hostname for all URL's, and can't use the IP address or aliases for the same site unless you *manually* set them all up as ServerAlias options. If feasible: get a separate IP address for the separate service, set it up as a virtual IP address, and set up a different IP based virtual host to separate out the functions of bugzilla and Subversion. It's also possible to set up Subversion as a subdirectory on the same server, by using "https://hostname/svn/"; as the URL to work with. https://[whatver]/svn can then be set to "Redirect" to to the Subversion URL. just to avoid confusion.
Corrupted revisions - need help
Hi there, I'm the sysadmin for our small company (8 employees) and we're running all our shared files over a subversion server. Some time ago our server had faulty memory which resulted in corrupt entries being written to the underlying fsfs db, later propagating to backups too. This resulted in four corrupt revisions in my /var/svn/myrepo/db/revs/, one of which I managed to fix manually with fsfsverify and a whole lot of hacking/fudging. The other three however are beyond me and I can't afford to spend days of trying to figure out how to fix it (and fsfsverify can't do it either, it keeps choking on the same issue). The problem is that I cannot take a full backup of my repository or create a new working copy from scratch as any command (e.g. svnadmin verify, svn co etc.) that comes across these revisions chokes and dies, always with the dreaded "Decompression of svndiff data failed" error. So, I'm wondering if anyone from the community can help me. I think I still have all of the original files which got written or amended during the three broken revisions (in one or more working copies), but one of these revisions is about 1.5GB so sharing is a bit tricky (the other two are 23MB and 1.7MB). I'm even willing to pay somebody to do the job if that's what's necessary, I only want to recreate my repository from scratch as a LAST resort as I would lose all of my history. Gunther
RE: SVN Server Configuration To Restrict SVN Client Version
Hi Daniel, Thanks for the response. As I think you understand, enforcing restrictions on the SVN client version is not aimed at preventing intentional spoofing, but rather human error and occasionally, sloth. In both cases, a refusal from the repository to accept access is generally all that is needed to prompt the user to comply. (Forging the version is much more work than installing the proper package.) From your response and the thread you pointed at, I understand that there is no plan to integrate this capability before the 1.8 release, so I'll probably fall back to plan B - which is to check the SVN client version as part of the project build process. Not my first choice (and has some obvious holes), but it'll have to do until then. Thanks Again, Nathan -Original Message- From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] Sent: Mon 11/19/2012 5:35 AM To: Nathan Frid Cc: users@subversion.apache.org Subject: Re: SVN Server Configuration To Restrict SVN Client Version First of all: there is nothing you can do to prevent people from self-compiling a 1.0 client that identifies as a 1.9 client. Now, with that out of the way: - You today can use the 'capabilities' argument to the 'start-commit' to approximate client version. - See http://subversion.tigris.org/issues/show_bug.cgi?id=4124 , to be included in 1.8.0: http://subversion.apache.org/docs/release-notes/1.8#ephemeral-txnprops Nathan Frid wrote on Sun, Nov 18, 2012 at 13:56:06 +0200: > Hi All, > > > > Having upgraded and deployed SVN 1.7 some time ago for > the repositories I manage, I am still encountering users who have not > upgraded from 1.6, despite repeated requests. Worse yet, the Linux > distribution we use doesn't package SVN 1.7 out-of-the-box, so sometimes > simple human error results in use of an old client. I would like to > configure the SVN server to reject access (or at least write access) > from pre-1.7 clients. > > > > I found nothing helpful in the SVN book and searching through the > mailing-list archives, I found only an old thread from 2009 which did > not provide a solution. The responses were more along the lines of > "what for?". But I have found pressing needs to enforce > standardization: > > > > 1) From an administrative/support perspective, it is MUCH easier to > support the same, or a minimum, version across all users in the > organization than deal with the variations in versions, especially > regarding bugs long since resolved. > > 2) SVN 1.6 handles merge tracking for sub-tree merges differently > than SVN 1.7 regarding what the 1.7 release notes call "reduced subtree > mergeinfo recording". This was one of the important (for us, at least) > improvements in SVN 1.7, as it makes the change logs much easier to > read, but according to the release notes, "Best results will be achieved > for new branches created and maintained exclusively with 1.7 clients". > So to fully realize the benefit, I have to restrict the client version. > Worse yet, I recently encountered a tree conflict due to 1.6's handling > of subtree mergeinfo. Say we have a branch A. A user with a 1.6 client > further branches "A", and through merge operations, manages to cause SVN > to track mergeinfo for a single file, "file.txt". Following > reintegration, a new branch "B" is created. After "B" was created, > "file.txt" is deleted from "A". On "B" development continues, including > branching and merging, but no content changes are made to "file.txt". > Upon reintegration of "B" to "A", a spurious tree conflict is detected > because the mergeinfo of "file.txt" on "B" was modified (for no good > reason), while that same file was deleted on "A". > > > > Does anyone have a solution or could point me in the right direction? > > > > Thanks, > > Nathan > > > > > > > > This footnote confirms that this email message has been scanned by > PineApp Mail-SeCure for the presence of malicious code, vandals & computer > viruses(187). > > > This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(100). This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42).
Re: Corrupted revisions - need help
On Mon, Nov 19, 2012 at 04:11:01PM +0200, Gunther Mayer wrote: > So, I'm wondering if anyone from the community can help me. I think > I still have all of the original files which got written or amended > during the three broken revisions (in one or more working copies), > but one of these revisions is about 1.5GB so sharing is a bit tricky > (the other two are 23MB and 1.7MB). I'm even willing to pay somebody > to do the job if that's what's necessary, I only want to recreate my > repository from scratch as a LAST resort as I would lose all of my > history. I've dealt with similar corruption problems in the past, where original fulltext file content was still available. So maybe this hint will help you: You might be able to create good representations by committing the fulltext files to a fresh temporary repository, possibly in multiple commits in the right order if you have more than one version of a file available. Extract these reps from the FSFS data of the temporary repository and stitch them into the broken repository at appropriate places, recalculating checksums where necessary, and tweaking offsets and maybe adding some padding if necessary. In case the good reps use less space than the bad ones, or the exact same amount, they can be made to work fairly easily. If they end up being larger things gets a bit more tricky. Note that due to the way FSFS revisions are parsed by Subversion (it looks at the end of the file for the changed-path data section offset first) you can move the changed-path data section further down to create more space in an existing revision file -- but you cannot move any other existing sections by even a single bit! I've managed to fix several corrupt revisions like this. There was a similar problem at the time, an elego customer's the SVN server was running in a VM and when the host computer unexpectedly lost power revision data in several FSFS files didn't get saved to the physical disks on time... oops! They were able to get some fulltext files from working copies which we could use to recreate some of the lost reps. Some related reading material (read in given order): https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/fs-history https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure Good luck!
Re: Corrupted revisions - need help
On Mon, Nov 19, 2012 at 9:11 AM, Gunther Mayer wrote: > Hi there, > > I'm the sysadmin for our small company (8 employees) and we're running all > our shared files over a subversion server. Some time ago our server had > faulty memory which resulted in corrupt entries being written to the > underlying fsfs db, later propagating to backups too. This resulted in four > corrupt revisions in my /var/svn/myrepo/db/revs/, one of which I managed > to fix manually with fsfsverify and a whole lot of hacking/fudging. The > other three however are beyond me and I can't afford to spend days of trying > to figure out how to fix it (and fsfsverify can't do it either, it keeps > choking on the same issue). The problem is that I cannot take a full backup > of my repository or create a new working copy from scratch as any command > (e.g. svnadmin verify, svn co etc.) that comes across these revisions chokes > and dies, always with the dreaded "Decompression of svndiff data failed" > error. Which version of Subversion are you running with? Do you have the latest revisions, to use the latest repair tools? And can you do an export of the current contents, set aside the old repository, and switch people to the new repo with the necessary tags, but without the corrupted history? This is an approach I've used successfully for people migrating among source control systems or cleaning up projects where inappropriae data was in the primary repository. (Spurious DVD images and files with passwords were particularly common problems.)
Subversion 1.6.12 does not work on XP/DLL entry point issues.
Hi, I am trying to get the old version of subversion (1.6.12) to work on my box (downloaded from http://sourceforge.net/projects/win32svn/files/1.6.12/ as msi or zip) and getting the DLL issues. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_client_status5 could not be located in the dynamic link library libsvn_client-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_diff_mem_string_output_unified2 could not be located in the dynamic link library libsvn_diff-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_fspath__split could not be located in the dynamic link library libsvn_subr-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_cstring_strtoui64 could not be located in the dynamic link library libsvn_subr-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_hash__get_cstring could not be located in the dynamic link library libsvn_subr-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point _apr_pollset_create_ex@20 could not be located in the dynamic link library libapr-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_fs_change_rev_prop2 could not be located in the dynamic link library libsvn_fs-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point _apr_hash_do@12 could not be located in the dynamic link library libapr-1.dll. Application popup: svn.exe - Entry Point Not Found : The procedure entry point svn_dirent_basename could not be located in the dynamic link library libsvn_subr-1.dll. Application popup: svn.exe - Ordinal Not Found : The ordinal 4540 could not be located in the dynamic link library LIBEAY32.dll. There are no any of these DLLs in path other than that comes from pre-compiled exe file. Could you suggest what the wrong DLL is and there to get the right version? Regards, Dmitry ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barclays.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking products and services to its clients through Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
JavaHL propertyGet handling in org.tigris.subversion package
Hi,
I've been having a problem with the 1.7 JavaHL implementation in the
org.tigris.subversion package. As I understand the code, this has been
written as a wrapper around the new org.apache.subversion package. The
propertyGet method is calling new String() around the byte[] value returned
from the new interface's equivalent method. The problem is that when this
returns null, the old interface method throws a NullPointerException rather
than returning null.
This is somewhat related to the discussion in
http://subversion.tigris.org/issues/show_bug.cgi?id=3770
although it's of a slightly different character.
I suggest the following change:
Index: SVNClient.java
===
--- SVNClient.java(revision 1411518)
+++ SVNClient.java(working copy)
@@ -2110,10 +2110,10 @@
{
try
{
-return new PropertyData(path, name,
-new String(aSVNClient.propertyGet(path, name,
-revision == null ? null : revision.toApache(),
-pegRevision == null ? null :
pegRevision.toApache(;
+byte[] propertyBytes = aSVNClient.propertyGet(path, name,
+revision == null ? null : revision.toApache(),
+pegRevision == null ? null : pegRevision.toApache());
+return propertyBytes == null ? null : new PropertyData(path,
name, new String(propertyBytes));
}
catch (org.apache.subversion.javahl.ClientException ex)
{
What do you think?
Cheers
Conor
Re: Corrupted revisions - need help
Stefan Sperling wrote on Mon, Nov 19, 2012 at 21:07:59 +0100: > Extract these reps from the FSFS data of the temporary repository and > stitch them into the broken repository at appropriate places, recalculating > checksums where necessary, Instead of recalculating, you ought to be able to set them to all-zeroes.
Re: Subversion 1.6.12 does not work on XP/DLL entry point issues.
svn_client_status5 was added in 1.7 (see subversion/include/svn_client.h in the source tree), so it seems you are using a 1.7 svn.exe with a 1.6 libsvn_client-1.dll. dmitry.lyse...@barclays.com wrote on Mon, Nov 19, 2012 at 16:41:57 -0500: > Hi, > > I am trying to get the old version of subversion (1.6.12) to work on my box > (downloaded from http://sourceforge.net/projects/win32svn/files/1.6.12/ as > msi or zip) and getting the DLL issues. > > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_client_status5 could not be located in the dynamic link library > libsvn_client-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_diff_mem_string_output_unified2 could not be located in the dynamic > link library libsvn_diff-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_fspath__split could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_cstring_strtoui64 could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_hash__get_cstring could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point _apr_pollset_create_ex@20 could not be located in the dynamic link > library libapr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_fs_change_rev_prop2 could not be located in the dynamic link > library libsvn_fs-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point _apr_hash_do@12 could not be located in the dynamic link library > libapr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_dirent_basename could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Ordinal Not Found : The ordinal 4540 could not > be located in the dynamic link library LIBEAY32.dll. > > > There are no any of these DLLs in path other than that comes from > pre-compiled exe file. > > Could you suggest what the wrong DLL is and there to get the right version? > > Regards, > Dmitry
Re: Subversion 1.6.12 does not work on XP/DLL entry point issues.
I forgot to mention: to see what release an API was added in, another option is to browse the compiled doxygen docs on our site: http://subversion.apache.org/docs/. dmitry.lyse...@barclays.com wrote on Mon, Nov 19, 2012 at 16:41:57 -0500: > Hi, > > I am trying to get the old version of subversion (1.6.12) to work on my box > (downloaded from http://sourceforge.net/projects/win32svn/files/1.6.12/ as > msi or zip) and getting the DLL issues. > > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_client_status5 could not be located in the dynamic link library > libsvn_client-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_diff_mem_string_output_unified2 could not be located in the dynamic > link library libsvn_diff-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_fspath__split could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_cstring_strtoui64 could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_hash__get_cstring could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point _apr_pollset_create_ex@20 could not be located in the dynamic link > library libapr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_fs_change_rev_prop2 could not be located in the dynamic link > library libsvn_fs-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point _apr_hash_do@12 could not be located in the dynamic link library > libapr-1.dll. > Application popup: svn.exe - Entry Point Not Found : The procedure entry > point svn_dirent_basename could not be located in the dynamic link library > libsvn_subr-1.dll. > Application popup: svn.exe - Ordinal Not Found : The ordinal 4540 could not > be located in the dynamic link library LIBEAY32.dll. > > > There are no any of these DLLs in path other than that comes from > pre-compiled exe file. > > Could you suggest what the wrong DLL is and there to get the right version? > > Regards, > Dmitry > > > > > > > ___ > > This e-mail may contain information that is confidential, privileged or > otherwise protected from > disclosure. If you are not an intended recipient of this e-mail, do not > duplicate or redistribute > it by any means. Please delete it and any attachments and notify the sender > that you have received > it in error. Unless specifically indicated, this e-mail is not an offer to > buy or sell or a > solicitation to buy or sell any securities, investment products or other > financial product or > service, an official confirmation of any transaction, or an official > statement of Barclays. Any > views or opinions presented are solely those of the author and do not > necessarily represent those > of Barclays. This e-mail is subject to terms available at the following link: > www.barclays.com/emaildisclaimer. > By messaging with Barclays you consent to the foregoing. Barclays offers > premier investment banking > products and services to its clients through Barclays Bank PLC, a company > registered in England > (number 1026167) with its registered office at 1 Churchill Place, London, E14 > 5HP. This email may > relate to or be sent from other members of the Barclays Group. > > ___
