Compiling svn + httpd for windows python 2.x
Folks,
We use subversion with Trac behind httpd on Windows Server. As Trac is written
in "old" Python (2.x), I have had to resort to building everything from source.
This is not simple and so I thought I would publish my notes here in case it
helps anyone else and in the hope that if I have made any mistakes, someone
will be kind enough to point them out to me!
~ Mark C
These are my notes for building Apache httpd and subversion for use with Trac
[1]. All of the components need to be built using the same compiler to avoid
run-time issues and, since Trac currently relies on Python 2.x, that means
Visual Studio 2008.
[1] http://trac.edgewall.org
Pre-requisites
--
All of the following assumes a suitable build environment, which for me is:-
- Windows 7 Enterprise (virtual machine)
- Visual Studio Professional 2008 (plus SP1) == VC9
- Python 2.x (currently 2.7.11) [2]
- PyWin32 [3]
- StrawberryPerl [4]
- "awk" [5] (can't remember why)
- SCons [6] for building the Serf library
- CMake [7] for building the PCRE library
- SWIG [8] for the Python bindings
- 7-zip [9] for unpacking all the downloads!
[2] https://www.python.org/downloads/
[3] http://sourceforge.net/projects/pywin32/files/pywin32/
[4] http://strawberryperl.com/
[5] https://www.cs.princeton.edu/~bwk/btl.mirror/
[6] http://www.scons.org/
[7] http://www.cmake.org/download/
[8] http://www.swig.org/download.html
[9] http://7-zip.org
Folders
---
In the following I assume the following folder structure:-
D:\svn
D:\svn\httpd
D:\svn\httpd\srclib\apr
D:\svn\httpd\srclib\apr-iconv
D:\svn\httpd\srclib\apr-util
D:\svn\httpd\srclib\openssl
D:\svn\httpd\srclib\pcre
D:\svn\serf
D:\svn\sqlite
D:\svn\src
D:\svn\zlib
===
1) Apache httpd
Download the latest httpd source tarball: https://httpd.apache.org/download.cgi
Unpack the source to:
D:\svn\httpd
---
2) APR source tarballs
Download from: https://apr.apache.org/download.cgi
Unpack the archives to the * httpd\srclib * folder:
D:\svn\httpd\srclib\apr
D:\svn\httpd\srclib\apr-iconv
D:\svn\httpd\srclib\apr-util
Remember to remove the version numbers from the folder names!
Note: last I tried, apr 1.5.2 causes a number of build errors:
http://mail-archives.apache.org/mod_mbox/apr-dev/201504.mbox/%3c553db43a.3020...@gknw.net%3e
Reverting to 1.5.1... works
---
3) OpenSSL
Download the latest OpenSSL source: http://www.openssl.org/source/
Unpack the source to the srclib folder:
D:\svn\httpd\srclib\openssl
See also: http://wiki.openssl.org/index.php/Compilation_and_Installation
---
4) Download the latest PCRE source: http://www.pcre.org/
Unpack the PCRE (Perl Compatible Regular Expressions) to the srclib folder:
D:\svn\httpd\srclib\pcre
---
5) Fix line endings
Run `lineends.pl` from the root folder to convert line endings from *nix to
windoze standard (NB: recurses down from current folder):
{{{
d:\> cd svn\httpd
d:\svn\httpd\> perl srclib\apr\build\lineends.pl
}}}
---
6) Build OpenSSL
-
Run the following in a * Visual Studio * command prompt window...
{{{
cd \svn\httpd\srclib\openssl
perl Configure no-asm no-comp no-rc5 no-idea no-ssl2 enable-mdc2 VC-WIN32
ms\do_ms.bat
nmake -f ms\ntdll.mak
}}}
Note: specifying "no-ssl2 no-ssl3" will result in linker errors!
---
7) Build PCRE
--
[from http://wiki.greenstone.org/doku.php?id=en:developer:compiling_apache]
- Read `srclib/pcre/NON-AUTOTOOLS-BUILD`
section "BUILDING PCRE ON WINDOWS WITH CMAKE"
- Run the CMake GUI from a VS2008 command prompt ("start cmake-gui")
- Specify the source and output folders as ...\srclib\pcre
- Hit `Configure`
- Select `NMake Makefiles` for the generator, using default native compilers
- Edit the red block of values:
- BUILD_SHARED LIBS
- Set CMAKE_BUILD_TYPES to RelWithDebInfo
- Set CMAKE_INSTALL_PREFIX to the \srclib\pcre folder
? Set both unicode support flags (seems likely to be useful?)
? not sure about PCRE_NEWLINE for windoze? default: LF (*nix)
- Hit `Configure` again, then `Generate` (then close cmake-gui).
- From the output folder (e.g. srclib\pcre):
{{{
nmake -f makefile
}}}
...should make pcre.dll in the pcre folder, where the apache makefile expects
it to be.
---
8) Prepare apr, apr-util, apr-iconv, httpd & modules...
--
** First ** convert the project files (this avoids lots of RC errors about
e
Re: Compiling svn + httpd for windows python 2.x
Hi Mark, Folks, We use subversion with Trac behind httpd on Windows Server. As Trac is written in "old" Python (2.x), I have had to resort to building everything from source. This is not simple and so I thought I would publish my notes here in case it helps anyone else and in the hope that if I have made any mistakes, someone will be kind enough to point them out to me! ~ Mark C These are my notes for building Apache httpd and subversion for use with Trac [1]. All of the components need to be built using the same compiler to avoid run-time issues and, since Trac currently relies on Python 2.x, that means Visual Studio 2008. Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN [1] is built using VS 2015 Update 1 (the upcoming builds will use VS 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any issue related to that. [1] http://www.luke1410.de/typo3/index.php?id=97 -- Regards, Stefan Hett
RE: Compiling svn + httpd for windows python 2.x
> -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 12:38 > > Hi Mark, > > > Folks, > > > > We use subversion with Trac behind httpd on Windows Server. As Trac is > > written in "old" Python (2.x), I have had to resort to building everything > > from source. This is not simple and so I thought I would publish my notes > > here in case it helps anyone else and in the hope that if I have made any > > mistakes, someone will be kind enough to point them out to me! > > > > ~ Mark C > > > > These are my notes for building Apache httpd and subversion for use with > > Trac [1]. All of the components need to be built using the same compiler to > > avoid run-time issues and, since Trac currently relies on Python 2.x, that > > means Visual Studio 2008. > > Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN > [1] is built using VS 2015 Update 1 (the upcoming builds will use VS > 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any > issue related to that. > > [1] http://www.luke1410.de/typo3/index.php?id=97 I cannot remember specific references now but when I looked into this before it is because the official 2.x line is compiled using VC9. When memory is passed between applications relying on different version of the CRT then you can end up with hard to diagnose memory corruptions that eventually cause problems. Digging a bit I found this thread [1] that highlights a similar CRT issue in python modules such as psycopg2 (which I use for PostGreSQL) that use the CRT internally... [1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc If you can guarantee to me that isn't going to happen then it would make my life easier! ~ Mark C
Re: Compiling svn + httpd for windows python 2.x
On 6/22/2016 2:01 PM, Cooke, Mark wrote: -Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: 22 June 2016 12:38 Hi Mark, Folks, We use subversion with Trac behind httpd on Windows Server. As Trac is written in "old" Python (2.x), I have had to resort to building everything from source. This is not simple and so I thought I would publish my notes here in case it helps anyone else and in the hope that if I have made any mistakes, someone will be kind enough to point them out to me! ~ Mark C These are my notes for building Apache httpd and subversion for use with Trac [1]. All of the components need to be built using the same compiler to avoid run-time issues and, since Trac currently relies on Python 2.x, that means Visual Studio 2008. Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN [1] is built using VS 2015 Update 1 (the upcoming builds will use VS 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any issue related to that. [1] http://www.luke1410.de/typo3/index.php?id=97 I cannot remember specific references now but when I looked into this before it is because the official 2.x line is compiled using VC9. When memory is passed between applications relying on different version of the CRT then you can end up with hard to diagnose memory corruptions that eventually cause problems. This is correct. If you are building a project linking in the CRT, you should ensure that all DLLs and libraries you build with use the same CRT. Mixing different CRT versions is unsupported and you will have undefined behavior. The possibilities for memory corruptions is the most prominent effect one might observe, but there are other problems/issues this will cause too. Digging a bit I found this thread [1] that highlights a similar CRT issue in python modules such as psycopg2 (which I use for PostGreSQL) that use the CRT internally... [1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc As far as I skimmed through the thread the problem here is not with python being compiled using VC9, but rather the module the python script tries to load (psycopg2, which according to the web seems to be some postgre-sql-related library) was compiled with a different CRT than the Apache binaries. That's a general issue, yes, and that's why I don't distribute the svn-apache modules with MaxSVN, even though they are built as part of the buildprocess (and utilized for testing). It's imperative that the CRT for the Apache modules matches the ones used to build Apache and that only the distributor of the specific Windows Apache module can ensure. If you can guarantee to me that isn't going to happen then it would make my life easier! I might miss something here which exceeds my knowledge (tbh I've only average experience with Apache httpd and python), but as long as there's nothing pulled in from python when you build Apache (and I'm quite sure that's not the case), python is just used as a build tool (for building SVN, Apache) and lateron as a script tool (from Apache). It doesn't matter how the python executable is build in this regard and which CRT it uses. It however matters a lot for the modules you'd pull in with the python import statement. Regards, Stefan Hett
RE: Serf
Hello, Thank you. I am able to install using root. But SVn version is not been displayed in GUI ( at bottom of the page). What changes to be made to get that? Example: [cid:image001.png@01D1CC69.20FCDD10] From: Stefan [mailto:luke1...@posteo.de] Sent: 2016, June, 21 6:11 PM To: users@subversion.apache.org Subject: Re: Serf Hi Anup, On 6/20/2016 15:48, Somashekarappa, Anup (CWM-NR) wrote: Hi Team, I am installing svn 1.9.4 and got the below error. Which distribution do you use? Or did you compile SVN yourself? “unrecognized url scheme for svn” When I searched it is because of serf/neon lib. So trying to install using the below link but it is not working. Did you forget to add the link? Any other steps to install those lib. Can that be installed using “yum”? if so, may I know the lib name? The error can be either due to serf/neon not being linked into the SVN executables, due to a malformed URL or due to some other issue. Can you post the exact command you were using (including the URL) as well as the output of svn --version ? Regards, Stefan ___ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Creating and Verifying a Reliable backup
Following is an update to my question of Jun 1, where I ask the following
question:
On Wed, Jun 1, 2016 at 9:58 AM, Michael Schwager wrote:
> ...
> My question is: How do I back (subversion repos) up reliably, and verify
> (them) so that I can deliver a 100% recovery guarantee to my boss?
> ...
> I have compiled subversion-1.9.4 on the server under
> /opt/subversion-1.9.4. If I run that version of svn hotcopy, it appears to
> work and svnverify exits successfully. But ... I find that a file is
> missing: repos2/db/rev-prop-atomics.shm .
>
I have implemented a script that performs the following, in abbreviated
Bash form. Note that I have enough disk space for the original repos
directories, plus 2 copies. I am backup up the whole enchilada to tape. And
archiving it to another pair of tapes monthly and taking one of them
offsite. There... that oughta do it :-) . Without further ado:
LOGFILE=/var/log/backup_svn.$(date +%a)
exec 1>&$LOGFILE
exec 2>&1
REPODIR=/home/svn/svn/repositories
HOTCOPYDIR=/home/svn/hotcopy
RSYNCDIR=/home/svn/rsync
RELIABLE_SVNADMIN=/opt/subversion-1.9.4/bin/svnadmin
EMAIL=usern...@example.com
# $repos is a space-separated list of all the directories in
/home/svn/svn/repositories
for repo in $repos; do
#
# VERIFY ORIGINAL
--
#
echo "***
*"
echo " REPO $repo pre-backup sanity check
***"
echo
""
svnadmin verify $repo || { mail -s "ERROR: SVN directory FATAL
error. This is a BIG problem. Backups are HALTED." $EMAIL < $LOGFILE; exit
1; }
#
# HOTCOPY
--
#
echo
""
echo " REPO $repo hotcopy
***"
echo
""
rm -rf $HOTCOPYDIR/$repo.1
[[ -e $HOTCOPYDIR/$repo ]] && mv $HOTCOPYDIR/$repo
$HOTCOPYDIR/$repo.1
$RELIABLE_SVNADMIN hotcopy $REPODIR/$repo $HOTCOPYDIR/$repo || {
mail -s "ERROR: svn hotcopy exited with nonzero status." $EMAIL < $LOGFILE;
exit 1; }
echo
""
echo " REPO $repo hotcopy verify
"
echo
""
svnadmin verify $HOTCOPYDIR/$repo || { mail -s "ERROR: SVN hotcopy
error. The original is fine, hotcopy is not." $EMAIL < $LOGFILE; exit 1; }
#
# RSYNC
#
echo
""
echo " REPO $repo rsync
*"
echo
""
rm -rf $RSYNCDIR/$repo.1
[[ -e $RSYNCDIR/$repo ]] && mv $RSYNCDIR/$repo $RSYNCDIR/$repo.1
$RELIABLE_SVNADMIN freeze $repo -- rsync -av $repo $RSYNCDIR/ || {
mail -s "ERROR: rsync of svn repo $repo exited with nonzero status." $EMAIL
< $LOGFILE; exit 1; }
echo
""
echo " REPO $repo rsync verify
**"
echo
""
svnadmin verify $RSYNCDIR/$repo || { mail -s "ERROR: SVN rsync
error. The original is fine, rsync is not." $EMAIL < $LOGFILE; exit 1; }
echo
""
echo " Do other directories: authorization and bin
***"
echo
""
cd $REPODIR/..
rm -rf $RSYNCDIR/authorization.1
[[ -e $RSYNCDIR/authorization ]] && mv $RSYNCDIR/authorization
$RSYNCDIR/authorization.1
rm -rf $RSYNCDIR/bin.1
[[ -e $RSYNCDIR/bin ]] && mv $RSYNCDIR/bin $RSYNCDIR/bin.1
rsync -av authorization $RSYNCDIR/
rsync -av bin $RSYNCDIR/
--
-Mike Schwager
RE: Compiling svn + httpd for windows python 2.x
> -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 13:25 > To: users@subversion.apache.org > Subject: Re: Compiling svn + httpd for windows python 2.x > > On 6/22/2016 2:01 PM, Cooke, Mark wrote: > >> -Original Message- > >> From: Stefan Hett [mailto:ste...@egosoft.com] > >> Sent: 22 June 2016 12:38 > >> > >> Hi Mark, > >> > >>> Folks, > >>> > >>> We use subversion with Trac behind httpd on Windows Server. As Trac > >>> is written in "old" Python (2.x), I have had to resort to building > >>> everything from source. This is not simple and so I thought I would > >>> publish my notes here in case it helps anyone else and in the hope > >>> that if I have made any mistakes, someone will be kind enough to > >>> point them out to me! > >>> > >>> ~ Mark C > >>> > >>> These are my notes for building Apache httpd and subversion for use > >>> with Trac [1]. All of the components need to be built using the same > >>> compiler to avoid run-time issues and, since Trac currently relies on > >>> Python 2.x, that means Visual Studio 2008. > >> > >> Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN > >> [1] is built using VS 2015 Update 1 (the upcoming builds will use VS > >> 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any > >> issue related to that. > >> > >> [1] http://www.luke1410.de/typo3/index.php?id=97 > > > > I cannot remember specific references now but when I looked into this > > before it is because the official 2.x line is compiled using VC9. When > > memory is passed between applications relying on different version of > > the CRT then you can end up with hard to diagnose memory corruptions > > that eventually cause problems. > > This is correct. If you are building a project linking in the CRT, you > should ensure that all DLLs and libraries you build with use the same > CRT. Mixing different CRT versions is unsupported and you will have > undefined behavior. The possibilities for memory corruptions is the most > prominent effect one might observe, but there are other problems/issues > this will cause too. > > > > Digging a bit I found this thread [1] that highlights a similar CRT > > issue in python modules such as psycopg2 (which I use for PostGreSQL) > > that use the CRT internally... > > > > [1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc > > As far as I skimmed through the thread the problem here is not with > python being compiled using VC9, but rather the module the python script > tries to load (psycopg2, which according to the web seems to be some > postgre-sql-related library) was compiled with a different CRT than the > Apache binaries. That's a general issue, yes, and that's why I don't > distribute the svn-apache modules with MaxSVN, even though they are > built as part of the buildprocess (and utilized for testing). It's > imperative that the CRT for the Apache modules matches the ones used to > build Apache and that only the distributor of the specific Windows > Apache module can ensure. ...and that is my problem: Trac is running under py2.7 (via mod_wsgi from httpd) and using psycopg2 to connect to a PostGreSQL backend. AFAIK, python 2.7.x windows extensions should be built using VC++ 2008 to match the python build, so it is best if I build httpd, mod_wsgi and svn using that compiler too (especially as local policy means I need to be able to apply the latest e.g. OpenSSL updates as they come out). > > If you can guarantee to me that isn't going to happen then it would make my > > life easier! > > I might miss something here which exceeds my knowledge (tbh I've only > average experience with Apache httpd and python), but as long as there's > nothing pulled in from python when you build Apache (and I'm quite sure > that's not the case), python is just used as a build tool (for building > SVN, Apache) and lateron as a script tool (from Apache). It doesn't > matter how the python executable is build in this regard and which CRT > it uses. It however matters a lot for the modules you'd pull in with the > python import statement. Hmm, I started down this path because I had problems and I think they were as mentioned above. Life was good when Apache provided VC9 windows binaries and I could get svn with the python bindings from alagazam... ~ Mark C > Regards, > Stefan Hett
Re: Compiling svn + httpd for windows python 2.x
On 6/22/2016 5:30 PM, Cooke, Mark wrote: -Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: 22 June 2016 13:25 To: users@subversion.apache.org Subject: Re: Compiling svn + httpd for windows python 2.x On 6/22/2016 2:01 PM, Cooke, Mark wrote: -Original Message- From: Stefan Hett [mailto:ste...@egosoft.com] Sent: 22 June 2016 12:38 Hi Mark, Folks, We use subversion with Trac behind httpd on Windows Server. As Trac is written in "old" Python (2.x), I have had to resort to building everything from source. This is not simple and so I thought I would publish my notes here in case it helps anyone else and in the hope that if I have made any mistakes, someone will be kind enough to point them out to me! ~ Mark C These are my notes for building Apache httpd and subversion for use with Trac [1]. All of the components need to be built using the same compiler to avoid run-time issues and, since Trac currently relies on Python 2.x, that means Visual Studio 2008. Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN [1] is built using VS 2015 Update 1 (the upcoming builds will use VS 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any issue related to that. [1] http://www.luke1410.de/typo3/index.php?id=97 I cannot remember specific references now but when I looked into this before it is because the official 2.x line is compiled using VC9. When memory is passed between applications relying on different version of the CRT then you can end up with hard to diagnose memory corruptions that eventually cause problems. This is correct. If you are building a project linking in the CRT, you should ensure that all DLLs and libraries you build with use the same CRT. Mixing different CRT versions is unsupported and you will have undefined behavior. The possibilities for memory corruptions is the most prominent effect one might observe, but there are other problems/issues this will cause too. Digging a bit I found this thread [1] that highlights a similar CRT issue in python modules such as psycopg2 (which I use for PostGreSQL) that use the CRT internally... [1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc As far as I skimmed through the thread the problem here is not with python being compiled using VC9, but rather the module the python script tries to load (psycopg2, which according to the web seems to be some postgre-sql-related library) was compiled with a different CRT than the Apache binaries. That's a general issue, yes, and that's why I don't distribute the svn-apache modules with MaxSVN, even though they are built as part of the buildprocess (and utilized for testing). It's imperative that the CRT for the Apache modules matches the ones used to build Apache and that only the distributor of the specific Windows Apache module can ensure. ...and that is my problem: Trac is running under py2.7 (via mod_wsgi from httpd) and using psycopg2 to connect to a PostGreSQL backend. AFAIK, python 2.7.x windows extensions should be built using VC++ 2008 to match the python build, so it is best if I build httpd, mod_wsgi and svn using that compiler too (especially as local policy means I need to be able to apply the latest e.g. OpenSSL updates as they come out). Certainly that's working. But since you are recompiling psycopg2 yourself, why don't you just recompile that then using VS 2015? Or are there other python libs involved? -- Regards, Stefan Hett
Re: Compiling svn + httpd for windows python 2.x
Hello Mark, On Wed, Jun 22, 2016 at 1:46 PM, Cooke, Mark wrote: > > Folks, > > We use subversion with Trac behind httpd on Windows Server. As Trac is > written in "old" Python (2.x), I have had to resort to building everything > from source. This is not simple and so I thought I would publish my notes > here in case it helps anyone else and in the hope that if I have made any > mistakes, someone will be kind enough to point them out to me! You say that you had to resort to building SVN and HTTPD on Windows from source. Does it mean that all the existing SVN server packages such as VisualSVN Server don't work for you by some reason? Why? I'm asking because VisualSVN Server comes with Python 2.7.x bindings and `mod_wsgi` which should perfectly work with Trac. -- With best regards, Pavel Lyalyakin VisualSVN Team
RE: Compiling svn + httpd for windows python 2.x
> -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 17:03 > > On 6/22/2016 5:30 PM, Cooke, Mark wrote: > > > >> -Original Message- > >> From: Stefan Hett [mailto:ste...@egosoft.com] > >> Sent: 22 June 2016 13:25 > >> > >> On 6/22/2016 2:01 PM, Cooke, Mark wrote: > -Original Message- > From: Stefan Hett [mailto:ste...@egosoft.com] > Sent: 22 June 2016 12:38 > > Hi Mark, > > > Folks, > > > > We use subversion with Trac behind httpd on Windows Server. As Trac > > is written in "old" Python (2.x), I have had to resort to building > > everything from source. This is not simple and so I thought I would > > publish my notes here in case it helps anyone else and in the hope > > that if I have made any mistakes, someone will be kind enough to > > point them out to me! > > > > ~ Mark C > > > > These are my notes for building Apache httpd and subversion for use > > with Trac [1]. All of the components need to be built using the same > > compiler to avoid run-time issues and, since Trac currently relies on > > Python 2.x, that means Visual Studio 2008. > Why does Python 2.x (aka: 2.7.11) imply having to use VS 2008? MaxSVN > [1] is built using VS 2015 Update 1 (the upcoming builds will use VS > 2015 Update 2) in combination with Python 2.7.11 and I'm unaware of any > issue related to that. > > [1] http://www.luke1410.de/typo3/index.php?id=97 > >>> I cannot remember specific references now but when I looked into this > >>> before it is because the official 2.x line is compiled using VC9. When > >>> memory is passed between applications relying on different version of > >>> the CRT then you can end up with hard to diagnose memory corruptions > >>> that eventually cause problems. > >> This is correct. If you are building a project linking in the CRT, you > >> should ensure that all DLLs and libraries you build with use the same > >> CRT. Mixing different CRT versions is unsupported and you will have > >> undefined behavior. The possibilities for memory corruptions is the most > >> prominent effect one might observe, but there are other problems/issues > >> this will cause too. > >>> Digging a bit I found this thread [1] that highlights a similar CRT > >>> issue in python modules such as psycopg2 (which I use for PostGreSQL) > >>> that use the CRT internally... > >>> > >>> [1] https://groups.google.com/forum/#!topic/modwsgi/ATtKX6qWLXc > >> As far as I skimmed through the thread the problem here is not with > >> python being compiled using VC9, but rather the module the python script > >> tries to load (psycopg2, which according to the web seems to be some > >> postgre-sql-related library) was compiled with a different CRT than the > >> Apache binaries. That's a general issue, yes, and that's why I don't > >> distribute the svn-apache modules with MaxSVN, even though they are > >> built as part of the buildprocess (and utilized for testing). It's > >> imperative that the CRT for the Apache modules matches the ones used to > >> build Apache and that only the distributor of the specific Windows > >> Apache module can ensure. > > ...and that is my problem: Trac is running under py2.7 (via mod_wsgi from > > httpd) and using psycopg2 to connect to a PostGreSQL backend. AFAIK, python > > 2.7.x windows extensions should be built using VC++ 2008 to match the python > > build, so it is best if I build httpd, mod_wsgi and svn using that compiler > > too (especially as local policy means I need to be able to apply the latest > > e.g. OpenSSL updates as they come out). > > Certainly that's working. But since you are recompiling psycopg2 > yourself, why don't you just recompile that then using VS 2015? Or are > there other python libs involved? I am not compiling python or any of the support libs that we use, I decided to compile httpd and svn instead. I will have another go with VisualSVN again to see if it works for us now. > -- > Regards, > Stefan Hett
Re: Serf
Hi Anup, > > Hello, > > > > Thank you. I am able to install using root. > > > > > > But SVn version is not been displayed in GUI ( at bottom of the page). > What changes to be made to get that? > > > > Example: > > > I fear we are facing some language problems here... You said you got the error message: "unrecognized url scheme for svn". So that suggest you somehow executed some SVN command. If you used a GUI interface rather than the SVN command line client, can you state which GUI you are using? If svn is not a recognized command on your machine, that suggests that either no svn command line client is installed or you do not have permission to execute it (or it might not be in the path on your machine). Please google the web to find some instructions applicable to your platform to get that installed. That should be faster than passing on several mails here trying to explain how this is done on your platform, I think. > > > > > *From:*Stefan [mailto:luke1...@posteo.de] > *Sent:* 2016, June, 21 6:11 PM > *To:* users@subversion.apache.org > *Subject:* Re: Serf > > > > Hi Anup, > On 6/20/2016 15:48, Somashekarappa, Anup (CWM-NR) wrote: > > > > Hi Team, > > > > I am installing svn 1.9.4 and got the below error. > > Which distribution do you use? Or did you compile SVN yourself? > > > > “unrecognized url scheme for svn” > > > > When I searched it is because of serf/neon lib. So trying to install > using the below link but it is not working. > > Did you forget to add the link? > > > > Any other steps to install those lib. Can that be installed using > “yum”? if so, may I know the lib name? > > The error can be either due to serf/neon not being linked into the SVN > executables, due to a malformed URL or due to some other issue. > Can you post the exact command you were using (including the URL) as > well as the output of svn --version ? > > Regards, > Stefan > > ___ > > This email is intended only for the use of the individual(s) to whom > it is addressed and may be privileged and confidential. > Unauthorised use or disclosure is prohibited. If you receive This > e-mail in error, please advise immediately and delete the original > message. > This message may have been altered without your or our knowledge and > the sender does not accept any liability for any errors or omissions > in the message. > > Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas > aux droits et obligations qui s'y rapportent. > Toute diffusion, utilisation ou copie de ce message ou des > renseignements qu'il contient par une personne autre que le (les) > destinataire(s) désigné(s) est interdite. > Si vous recevez ce courriel par erreur, veuillez m'en aviser > immédiatement, par retour de courriel ou par un autre moyen. > Regards, Stefan smime.p7s Description: S/MIME Cryptographic Signature
Re: Serf
On 22.06.2016 21:19, Stefan wrote: > Hi Anup, >> >> Hello, >> >> >> >> Thank you. I am able to install using root. >> >> >> >> >> >> But SVn version is not been displayed in GUI ( at bottom of the >> page). What changes to be made to get that? >> >> >> >> Example: >> >> >> > I fear we are facing some language problems here... > You said you got the error message: "unrecognized url scheme for svn". > So that suggest you somehow executed some SVN command. If you used a > GUI interface rather than the SVN command line client, can you state > which GUI you are using? What you see in the picture above is the default directory listing that's generated if you point a plain ol' web browser at a Subversion repository. There's no GUI beyond a web browser there. Best guess is that httpd is not loading the 1.9.x mod_dav_svn for whatever reason, and that Subversion 1.7.8 is also installed on the server. -- Brane
Re: Which is the best tool /process to migrate VSS (with history) to Subversion
On Jun 21, 2016, at 11:44 PM, Branko Čibej wrote: > On 20.06.2016 15:04, Nico Kadel-Garcia wrote: >> Unless you have a compelling need for history, I'd suggest you do a >> simple export o a working copy from VSS to a simple export in >> Subversiont. > > I have to say I'm mildly put off by your repeated suggestions on this > list to throw away history to make things "easier" during migrations. Me too. When a person asks how to migrate with history, I don't like seeing a response that says don't migrate the history. I am currently in the process of testing a migration of a Subversion repository with 14 years of history (which has previously been migrated from CVS) to a different VCS. Yes, I am preserving all the history. Yes, I am removing cruft during the conversion as well. Yes, a proper conversion can take some effort. Yes, it's worth it. But I don't have any experience with or advice for converting to VSS.
