Ryan Schmidt wrote:
> On Jan 28, 2008, at 21:55, Andy Levy wrote:
>
>> On Jan 28, 2008 10:27 PM, Ryan Schmidt wrote:
>>
>>> On Jan 28, 2008, at 19:37, John Peacock wrote:
>>>
>>>> Alexxoid wrote:
>>>>
>>>>> This is a not acceptable choice for me, because we are using linux
>>>>> server as the development server -- it includes apache + php
>>>>> applications.
>>>>
>>>> Then you should have said that before, so I could given you the
>>>> "correct" answer
>>>> the first time. ;-)
>>>>
>>>> The development server should have it's own working copy, that you
>>>> are not
>>>> sharing with a workstation. You should never share working copies
>>>> between
>>>> people or machines, because it can confuse you when you try and
>>>> commit changes.
>>>> Every working copy should be "local" and unique to that person/
>>>> process.
>>>
>>> [snip]
>>>
>>> He didn't say he was sharing a working copy. :) If he is sharing a
>>> working copy, then yes, he should stop that. But for example at the
>>> web design shop where I used to work, the developers also used
>>> Windows machines, and used TortoiseSVN to check out working copies
>>> onto Samba-mounted shares from a central Linux development server.
>>> These were private working copies for each developer, in their home
>>> directory on the Linux server. It worked. Something could be strange
>>> about Alexxoid's Samba setup that's preventing it from working for him.
>>
>> Ah, but he is "sharing" a WC between OSes, and that *is* discouraged.
>> If you've got svn:eol-style set to native, and use TSVN to operate on
>> the WC via Samba on a Linux server, you're going to have DOS/Windows
>> line-endings on your Linux host, which would normally expect *nix line
>> endings. Then there's also the possible issues with permissions,
>> symlinks, etc.
>
> Yup, for those reasons our policy was to never use svn:eol-style native
> (always use svn:eol-style LF and configure Windows editors to know how
> to deal with that) and never use symlinks. Permissions weren't a problem
> for us.
I try to mark all project files with svn:eol-style=LF property, but
problem stays... Also, I determine, that checkouting folder without any
subfolders completed without any errors...
My samba configuration file:
[global]
netbios name = MAINSERVER.IT
workgroup = TEST
server string = TEST Domain Server
hosts allow = 192.168.1.
security = user
encrypt passwords = yes
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
interfaces = lo eth0
bind interfaces only = yes
local master = yes
os level = 65
domain master = yes
preferred master = yes
null passwords = no
hide unreadable = yes
hide dot files = yes
domain logons = yes
logon path = \\Mainserver.it\home\.profile
logon drive = Z:
logon home = \\Mainserver.it\home
logon script = startup.cmd
wins support = yes
name resolve order = wins lmhosts host bcast
dns proxy = no
oplocks = no
level2 oplocks = no
kernel oplocks = no
time server = yes
log file = /var/log/samba/log.%m
max log size = 50
add user script = /usr/sbin/smbldap-useradd -m "%u"
add machine script = /usr/sbin/smbldap-useradd -w "%u"
add group script = /usr/sbin/smbldap-groupadd -p "%g"
add user to group script = /usr/sbin/smbldap-groupmod -m "%u" "%g"
delete user from group script = /usr/sbin/smbldap-groupmod -x "%u" "%g"
set primary group script = /usr/sbin/smbldap-usermod -g "%g" "%u"
passdb backend = ldapsam:ldap://192.168.1.1/
ldap delete dn = Yes
ldap ssl = no
winbind nested groups = no
ldap suffix = dc=mainserver,dc=it
ldap admin dn = cn=Manager,dc=mainserver,dc=it
ldap group suffix = ou=Group
ldap user suffix = ou=People
ldap machine suffix = ou=People
ldap idmap suffix = ou=Idmap
[work]
comment = Sources folder
path = /var/www
browseable = yes
writable = yes
write = yes
read only = no
create mask = 0666
directory mask = 0777
oplocks = no
level2 oplocks = no
kernel oplocks = no
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-29 20:59:44 CET