Greetings, Theodore H . Smith!
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
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
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.
svn import http://svn.mydomain.local/repos/mynewproject
Committed revision 1.
Fourth step is quite simple. Go to your test environment and checkout your new
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?
Andrey Repin (anrdaemon_at_freemail.ru) 02.04.2009, <19:40>
Sorry for my terrible english...
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-02 18:56:05 CEST