On Oct 7, 2011, at 04:09, Dalibor Karlović wrote: > > Sure, I'll lay it out: > - we're a small web development studio > - we have a development server which exposed one share to the team via Samba > - if we're developing a new site called foo.com, we create a working copy on > the server and make it available as foo.com.web in our local domain which > makes it accessible from each workstation right away > - this gives us a point to which anybody working on the site can hook up to > and we all can see exactly what's going on at any point in time > - also, the less tech-savy guys/gals (designers, copywriters, PMs) don't > need to setup their own entire work environment (server, database, virtual > hosts, etc), they just open the share and a browser and start working. > - we cannot automate the procedure because there's alot of different systems > on staff (WinXP, Win7, MacOSX, Fedora, Ubuntu, etc).
Having developers editing code in a single shared working copy means you lose many of the advantages using Subversion offers. > The one "working copy per user" has too high of a (time) cost here. (At least) one working copy per developer per project is what you should be striving to use. That way developers can work independently and don't step on each others' toes. In the small web development shop where I worked, we also had a central development server which ran the web server, database server and Subversion repository. A central working copy (for each project) was auto-updated via post-commit hook as described here: http://subversion.apache.org/faq.html#website-auto-update The web server was configured to allow access to this directory (e.g. http://dev.example.com/project1 or http://project1.dev.example.com). Nobody but the post-commit hook had permission to modify this directory; it was a pristine always-up-to-date copy of the project's trunk from the repository. Management and other non-developers could access this URL to see how things were going. Each developer got his or her own working copy(ies) on the development server as well. Each developer had a login on the server and could make working copies in their home directory's public_html folder. Our projects were engineered such that it was easy to run them from any URL, so our developers could access their own work areas like http://dev.example.com/~developer1/project1/workingcopy1. Developers could create and delete working copies as needed. If your projects are not engineered to work on any URL, and require that they be at a the root of the URL space, then you could manually set up each developer's working copies as new vhosts, like http://workingcopy1.project1.developer1.dev.example.com In our setup, we shared a single database instance among all working copies, so obviously developers had to be very careful when making schema changes to the database. The alternative would be to give each developer their own database instance, but that's tough to keep synchronized. We did ok with just a single instance, duplicating the database only as needed when making really involved backward-incompatible changes. Using a working copy stored on a Samba server is not recommended because you tend to run into permissions errors like you saw. We used Samba in our shop and for whatever reason it worked ok for our Windows users but not for me on Mac OS X so I just ssh'd in, or kept my working copies on my Mac and ran my own web server.
