From users-return-59-daniel=haxx.se@subversion.apache.org Thu Dec 17 10:54:41 2009 Return-Path: Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9) with SMTP id nBH9sd1e030902 for ; Thu, 17 Dec 2009 10:54:40 +0100 Received: (qmail 68059 invoked by uid 500); 17 Dec 2009 09:54:33 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 68051 invoked by uid 99); 17 Dec 2009 09:54:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Dec 2009 09:54:33 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: unknown amxip4:69.16.237.154mx:imap2.ephotozine.comip4:85.118.233.237mx:host3.ephotozine.comip4:85.118.234.131?all (nike.apache.org: encountered unrecognized mechanism during SPF processing of domain of david@ephotozine.com) Received: from [85.118.233.237] (HELO host3.ephotozine.com) (85.118.233.237) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Dec 2009 09:54:23 +0000 Received: from host-80-193-75-168.static.cable.virginmedia.com ([80.193.75.168] helo=[172.20.37.11]) by host3.ephotozine.com with esmtpa (Exim 4.69) (envelope-from ) id 1NLD3a-0001ul-8X; Thu, 17 Dec 2009 09:54:02 +0000 Message-ID: <4B29FFA9.4070800@ephotozine.com> Date: Thu, 17 Dec 2009 09:53:45 +0000 From: David Burleson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b2pre Thunderbird/3.0 MIME-Version: 1.0 To: Ryan Schmidt CC: users@subversion.apache.org Subject: Re: Ideal Subversion Setup References: <4B290429.8090706@ephotozine.com> <40AAACFF-BE17-44B7-8513-319B851E53CF@ryandesign.com> In-Reply-To: <40AAACFF-BE17-44B7-8513-319B851E53CF@ryandesign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host3.ephotozine.com X-AntiAbuse: Original Domain - subversion.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ephotozine.com X-Virus-Checked: Checked by ClamAV on apache.org Hi Ryan, Thanks for the reply. So there might be some hope. Let me elaborate on our setup. I've decided the first thing to do is to cut out the inbetween step of dragging files over. So I have setup a folder on our local linux webserver and setup apache web server to use it as a virtual host (to do testing). This works great. Now I need to sort out the symlinks for the images directory. We create the symlinks manually through command line (ssh). We are using TortoiseSVN as a way to create the checkout to be used on our Windows computers. So.... 1. Linux Server: create a directory for development area 2. Linux Server: setup apache to use the newly created directory as a virtual host 3. Windows PC: Browse to the newly created directory via the network 4. Windows PC: Right click on the directory and select SVNcheckout and checkout the repository 5. Linux Server: Create a symlink in the directory to another directory on the linux server So...how do I commit that symlink as a symlink and not commit the contents within it? And, what is the best way to preserve folder/dir permissions using chmod into a repository? Cheers for the help so far! David On 17/12/2009 03:33 AM, Ryan Schmidt wrote: > On Dec 16, 2009, at 10:00, David Burleson wrote: > > >> I have been using subversion with TortoiseSVN for a couple of years now. I work in a team of 3 web developers on multiple websites. Im starting to wonder if the way we use subversion and version control is the correct way. So, I have posted to ask advice on the best way to use Subversion in a web development team with multiple projects. >> >> We currently each have our own development area on a local web server for each project. We also each have our own SVNcheckout of each project. >> > Sounds good to me! > > >> Once we have checked out/updated our 'repo' we drag the contents over to our development area to work. Once we are finished working, we drag the files back over to our 'repo' and commit it. >> > Where you say "repo" you actually mean "working copy" (or "checkout"); the "repo" or repository is what you check out from and commit to, and there is only one of them, on your Subversion server. > > >> I have a feeling that the better process is to make your development area the SVNcheckout. >> > I would completely agree with that. You're making a lot of unnecessary error-prone work for yourselves by manually moving files around. > > >> My only problems is how subversion and TortoiseSVN handle symlinks and file/dir permissions. We have a couple of symlinks for folders like 'images' so we don't have to duplicate the directories on the webserver and some folders which we upload files too have 777 permissions and what not. I don't know if subversion or TortoiseSVN will pass these own and treat the symlink as a symlink and not a folder, and pass the permission into the 'repo' too. >> > Subversion handles symlinks just fine, but Windows does not. (There is no such thing as a symlink on Windows.) So I'm not clear on how you're using symlinks on Windows at all, unless you're using cygwin. In which case you should use a cygwin Subversion client, not a Windows Subversion client like TortoiseSVN. > > Subversion repositories do not store or retain file or directory permissions or ownership. The only exception is the execute bit on files, which can be preserved by setting the svn:executable property of that file to any value (which Subversion automatically does if you add a file that's executable). > >