On Tue, Nov 14, 2017 at 10:07 AM, Bo Berglund <bo.berglund_at_gmail.com> wrote:
> Thanks!
>
> Next issue is about Python:
> I have used Python in conjunction with WinCVS before (never programmed
> Python myself) and I did so by installing from the ActiveState Python
> distribution.
> Now I see that ActiveState only offers the x64 version of the
> installer, whereas python.org has both.
>
> Can cvs2svn use either one (32 or 64 bit)?
> And is any of them to be preferred (ActiveState or Python.org, 32 or
> 64 bit)?
>
> Furthermore the cvs2svn docs say:
> Requirements:
> ....
> - Python 2, version 2.4 or later. See http://www.python.org/. (cvs2svn
> does not work with Python 3.x.)
> - A compatible database library, usually gdbm, and the corresponding
> Python bindings. Neither dumbdbm nor standard dbm is sufficient.
>
> Is there any way to find out if the needed database library is
> included or not? And if not how does one go about getting it?
I think you're going to hurt yourself if you try to assemble cvs2svn
from scratch with individual components, installed separately and
built into a Windows environment. I *urge* you to save yourself a lot
of work and use 64-bit CygWin in a Windows environment, which can
contain up-to-date python, up-to-date command line Subversion tools
and a server, and a more reliably consistent scripting environment.
> I have to install all tools on a "clean" Windows 2016 server x64
> machine for the conversion.
See above.
> Oh! That brings up yet another point:
> On Windows Server 2016 it seems like Microsoft has included their web
> server (IIS), but I think that Apache is needed for SVN.
> How can one deal with that?
> Or is SVN a server all by itself?
You've a set of options, very well documented in the "Red Book" at
http://svnbook.red-bean.com/. Apache, or httpd as version 2.x is
called, with mod_svn, is a common approach and well supported. Apache
can run alongside IIS, or IIS ignored, as long as they do not run on
the same network ports. There is also "svnserve", the built-in server,
though it's not perhaps as flexible as httpd nor built into port 443
firewalls as commonly HTTPS is commonly supported. And there is also
"svn+ssh", which allows an SSH daemon with tuned credentials to allow
"svnserve" local access. I personally find svn+ssh more secure for
various reasons, especially because the Subversion command line tool
stores httpd credentials in plain text in a user's home directory, by
default, but folks on this list have previously expressed their
irritation at me for bringing that up.
I'd encourage you to use the simplest, most integrated tools you can
find for the server, and spend your development time on activating
time on reliable backup, and your user education time on getting users
accustomed to the new workflow.
Received on 2017-11-15 14:55:32 CET