On Tue, Jan 22, 2013 at 7:38 AM, Thorsten Schöning <tschoening_at_am-soft.de>wrote:
> Guten Tag ana kish,
> am Dienstag, 22. Januar 2013 um 07:57 schrieben Sie:
>
> > We were thinking about using a Windows VM machine for this. Is
> > it ok to go with VM?
>
> In general yes and besides what others think if you already have
> Windows experience and Windows users just use Windows, there's really
> no need to waste any time with Linux if you don't already have
> experience with it. Windows is safe, it is stable and it is easy to
> backup, especially as using a VM the problem isn't the guest at all,
> but how you save the VM. Using working copies on network shares for
> Windows clients would be a main reason for me to use a Windows Server
> as Samba sounds good in general but things like authenticating users,
> ACLs etc. are much easier with using Windows as server and client OS,
> especially if you have limited experience with Linux and Samba.
> It's just wasted time...
>
> Said that, things like using Subversion through a web server like httpd
> may be better supported on current Linux distributions, I would
> personally avoid any situation where I would need to compile anything
> for httpd and Subversion on Windows on my own. Therefore if I were you
> I would first decide on how your users will mainly access the repos and
> afterwards look which OS serves best. This doesn't mean that httpd and
> Subversion won't work on Windows, just that they may be situations
> were some modules aren't current enough or whatever.
>
>
Do people find themselves having to compile their own Apache & modules for
Windows often? There are lots of pre-built distributions which include
Apache.
One big win with running a distribution like VisualSVN Server (which uses
Apache) on Windows is the easy integration with your pre-existing Active
Directory infrastructure.
The biggest challenges (IME) in running Subversion on Windows are:
1) Hook scripts. Because BAT files suck, and getting messages from other
scripts called by your BAT files back to the client is a pain. You could
compile an EXE, but that just adds another layer to the hook development
process.
2) Case insensitivity
For #2: If your repository is in d:\repos\Code and you have SVNParentPath
pointed at d:\repos, and your per-directory authz specifies repos:/Code,
anyone attempting operations against http://server/parent/Codewill
succeed but
http://server/parent/code will get an error. However, if you allow
anonymous read but require authentication for write, users can check out
from http://server/parent/code because Apache will find it either way (due
to NTFS being case-preserving but not sensitive, by default), but it will
throw a 403 error when you attempt to commit, because that path isn't found
in the authz file.
Received on 2013-01-22 16:10:10 CET