[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Want to set up SVN for a web app

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Thu, 02 Apr 2009 12:23:31 -0500

Andrey Repin wrote:
> Greetings, Theodore H . Smith!
> Thanks, Theodore.
> You pretty much did what I was about to do myself.
> But I'm a step ahead of you, so let me explain what I've done so far, and
> where am I now, and what I need. My steps will be in random, but consequent
> order, without a division to SVN-specific, SVN-related and completely
> unrelated, but necessary steps.
> First, I've created a test environment, which is also to be my working place.
> Apache, PHP and MySQL bound in the same way as it is on production host, if
> possible (AND AFFORDABLE!!!) - with the same database layout and passwords.
> Make sure you have .svn and CVS directories masked out of direct access.
> for Apache, it is done by specifying
> RewriteEngine On
> RewriteRule "(.+/)?(\.svn|CVS)/" "/" [F,L]
> In either .htaccess file or VirtualHost configuration.
> Second, i've created a directory structure suitable for future project.
> On my local drive, independent from the test environment.
> It is a protorype of the production server /home/<username> directory, with
> only necessary entries in it, like:
> ~/lib - necessary 3rd-party libraries
> ~/inc - my own includes, hooks and hacks
> ~/data - the project server-side codebase
> ~/cgi-bin - if you're using CGI scripts in your webserver, you might be need
> to include some of them under version control.
> ~/htdocs - actual site directory, visible from the web. It contains static
> pages, graphics, JavaScript codebase.
> Filled that structure with what I have already. Let's assume I have static
> website of couple of HTML pages with images and tiny bit of JScript.
> Third, i've imported it all to SVN. Easy.
> cd temp/protofolder
> svn import http://svn.mydomain.local/repos/mynewproject
> Adding htdocs
> Adding htdocs\classtrees_Structures_Graph.html
> Adding htdocs\errors.html
> Adding htdocs\media
> Adding htdocs\media\stylesheet.css
> Adding htdocs\media\banner.css
> Adding htdocs\packages.html
> Adding htdocs\elementindex.html
> Adding htdocs\Structures_Graph
> Adding htdocs\Structures_Graph\_Structures_Graph_Manipulator_AcyclicTest_php.html
> Adding htdocs\Structures_Graph\_Structures_Graph_Node_php.html
> Adding htdocs\Structures_Graph\_Structures_Graph_Manipulator_TopologicalSorter_php.html
> Adding htdocs\Structures_Graph\Structures_Graph.html
> Adding htdocs\Structures_Graph\Structures_Graph_Manipulator_AcyclicTest.html
> Adding htdocs\Structures_Graph\tutorial_Structures_Graph.pkg.html
> Adding htdocs\Structures_Graph\Structures_Graph_Node.html
> Adding htdocs\Structures_Graph\Structures_Graph_Manipulator_TopologicalSorter.html
> Adding htdocs\Structures_Graph\_Structures_Graph_php.html
> Adding htdocs\todolist.html
> Adding htdocs\elementindex_Structures_Graph.html
> Adding htdocs\index.html
> Adding htdocs\li_Structures_Graph.html
> Adding lib
> Adding data
> Adding inc
> Committed revision 1.
> Fourth step is quite simple. Go to your test environment and checkout your new
> repository.
> I suppose you have some of these files already in place, because you were
> checking if your environment are working properly, so we use --force switch.
> svn co --force http://svn.mydomain.local/repos/mynewproject /path/to/test/environment
> Now, you start working in your test environment, can see your changes
> instantly, and do whatever you need to do with it.
> After your task is done, you committing changes to repository. As usual.
> Fifth step is to make these changes available to public.
> Here is the problem.
> 1. Making public server another (readonly) working copy... not wise. It
> increase filesystem load, and if it is a shared server, it would cost you
> additional money to extend the disk space to necessary size.
> 2. Continuous export's of the whole directory tree... not wise. Projects tend
> to grow in size, and every export, even if only few files were changed, would
> take alot of time and bandwidth.
> My problem so far, and what I can't find out myself.
> If there's a way to determine, which files in a repository has been changed
> since revision REV, and how to tell export to only pull these changed files?
> export does not take the --tergets switch, and I can't find out, how to alter
> the built-in diff command output. It's hard to read for me at first and not
> doing what I need (in this specific case) at last.
> Suggestions? Alternate ways?

One approach is to use a working copy as a staging location. Do an
update to the revision or switch to the tag that you want to push to
production, then use rsync or something similar to update the production
  machine(s) to match the staging copy. Rsync will only copy the
changed parts and will copy under a temporary file name, renaming only
when complete, and the -C option will make it skip the .svn metadata as
well as cvs.

   Les Mikesell
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-02 19:24:26 CEST

This is an archived mail posted to the Subversion Users mailing list.