On Apr 1, 2009, at 09:44, Theodore H. Smith wrote:
> Now, when you are developing a desktop app, you normally care about
> code in two places. One, on your computer, and two on a central server
> shared by your co-workers.
>
> That makes for a simple model. You test the app locally, and when you
> are happy, you try to merge your code back into the central server. OK
> great.
>
> But what about a web app? When the testing is done on the server? In
> this case, there is code in THREE locations.
>
> One, on your hard disk where you are editing the files. Two, on the
> server for testing. And three, on another location on the server, for
> live use (production).
>
> How does SVN fit into that? What is the "Best practice" (for someone
> who highly favours simplicity and ease of use) for this kind of set
> up?
>
> I still can't get my head around how a VC, would be set up for a web
> app.
>
> I appreciate my original question maybe wasn't so good. And I
> appreciate that you said you don't personally use SVN for web apps.
> Perhaps this question will get a better answer :)
I do use Subversion for web apps, so I can help.
You already understand that each developer will have their own
working copy in which to edit files. Now you need to decide where
that working copy will be and how they will view those changes in a
web browser. Will they have a complete apache / php / perl / java
server environment set up on their local workstation? If so, then (1)
their working copy will be on their local workstation, in a location
accessible to apache, and they will view it in the web browser by
using a URL beginning with http://localhost/ , for example http://
localhost/~username/project/ .
Or will the local workstation have no web server and only be used for
editing text files? If so, then you can do it one of two ways: (2a)
The developer has a working copy on the local workstation, makes
changes there, commits them, and then updates a second working copy
located on the test web server (for example in their home directory
on the test server) and checks his work in a web browser with a URL
on the test server like http://testserver/~username/project/ . If
additional changes are needed, the process is repeated. This can
result in lots of extra "oops" commits as developers have to commit
every time they want to test a page. It makes it more tedious to look
through the commit log later, especially as developers are less
likely to write meaningful commit messages since they have to commit
so often. The other option: (2b) The developer has a working copy
only on the test server and accesses it via some remote access
protocol, such as SMB, AFP, by ssh'ing in to the server, by using
Transmit to edit the files remotely via FTP, etc. We used this method
at the web shop where I worked -- using SMB to view the working copy
locally. Our Windows users used TortoiseSVN locally to manage the
remote working copy. There was something funny about our SMB
implementation such that my Mac didn't like running svn commands on
the remote working copy, so to run svn commands, I ssh'd in to the
testing server and ran them there instead. The disadvantage of this
method is the communication with the server for all working copy
operations makes it slower, and as I found out with our SMB
implementation, it can be buggy and not work quite right. I often
checked out working copies to my local machine instead, using the
strategy from (1) above.
For finally deploying a site to the production server, we made a tag
of the trunk or branch, and ssh'd in to the production server. The
production server has a working copy of the project. We used "svn
switch url://to/the/new/tag" to switch that working copy to the newly-
created tag. You could have apache on the production server pointing
directly at that working copy. But working copy updates are not
atomic, so during the update, your site is not in a consistent state.
And if the update fails halfway through, the site stays that way
until you run the command again. So instead we used "svn export" to
export the working copy to another directory, named the same as the
tag. Finally, once that was done, we deleted a symlink called
"current" and recreated it pointing at the new tag. And apache was
configured with the path of the symlink. So we a directory structure
like this on the production server:
data/
projects/
someproject/
workingcopy/
exports/
2009-03-27/
2009-04-01/
current -> exports/2009-04-01
And the VirtualHost would look something like this:
<VirtualHost someproject:*>
ServerName someproject
DocumentRoot /data/projects/someproject/current/htdocs
</VirtualHost>
We used a single repository containing all projects. This makes it
possible to "svn cp" parts of one project into another, if you find
that you want to reuse in a new project code that you've already
written in an old one. You can even "svn cp" an entire project to a
new directory if you want to start a new project that's similar to an
old one.
If you're very disciplined and decide that you only share code via
reusable modules, then you can do this via svn:externals (described
in the book), and it doesn't matter if your modules are in the same
repository or a different one.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1511893
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-02 01:46:26 CEST