On Tue, Jan 22, 2013 at 7:38 AM, Thorsten Schöning <tschoen...@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.
