On Tue, Jan 22, 2013 at 9:11 AM, Andy Levy <andy.levy_at_gmail.com> wrote:
>
>
> 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...
If you are using filesystem based access control to Subversion
repositories, you are already in deep trouble. Whether it's direct
file-based access on the relevant Windows server to check out local
working copies, or CIFS based network share access, there are some
real risks of corrupting the repository accidentally for anyone with
file system access to a Subversion server. And managing pre- or
post-script tools for multiple Windows, Linux, UNIX, or MacOS CIFS
clients that might also have access is a nightmare.
Subversion has a lightweight, flexible access structure with svn.conf
or in Apache configurations that should be more than sufficient for
only 10 users.
> 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
Big exclamation points on this one.
> 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/Code will 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:27:29 CET