This is a bit long (sorry) but it's a real problem and the detail is
necessary.
I'm wanting to put my website which includes the local html files and
php folders from the net (eg wordpress & Gallery) under subversion control.
The html side is straightforward enough (just import current site),
except that I want to have the PHP pages, such as the blogging/cms
system wordPress installed (and managed) as well, and they have their
own folders in the repository.
I've set up a repository as suggested in the Subversion book for the
vendor drops of Gallery and Wordpress and various wordpress plugins, the
the released versions as tags and the current version as the main
working version called (as suggested) "current" instead of the usual
"trunk".
Currently the repository is laid out as:
/Website/index.html <--- Original html website in here
+ /Topic1
+
/Vendors/Wordpress/current
+ /tags
+ /Gallery /current
+ /tags
+ /WP-Amazon/current
+ /tags
The site is currently laid out like:
/-index.html <-- svn://repo/website/
+
/topic1/index.html
+ /images
+
/wordpress/index.php <-- svn//repo/vendor/wordpress/current
+ /wp_admin/...
+ /wp_plugins/...
+
/Gallery/index.php <-- svn//repo/vendor/gallery/current
+ /images
I especially want to have the complete site version controlled as in the
past it's been awkward to figure how to revert back to earlier versions
of a site if a new plugin didn't work, or to keep local mods when an new
version of something (either a main project such as Wordpress or
Gallery), or a plugin becomes available (especially a year after the
original install :-)
Slightly Tricky Problem
=======================
If the top level of the site (the /index.html and the topic1/ folders
are committed by themselves (svn/repo/website) which I've done and works
well, then how do you get a directory from another part of the
repository (eg /wordpress) sitting **inside** the checked out /website
folder. You can do this but subversion seems to be a bit puzzled about
commits from the top level and seems to try to include the changes in
/wordpress as well.
==> While I'd rather not, I could handle this by:
- moving all the html files down one level (say into /site)
- setting up the / level of the site to pull the /site and
/wordpress folders in as svn:externals
- use server redirects so all the html files are still found
(so links from search engines don't give 404 errors)
More Tricky problem - Wordpress Plugins
=======================================
Wordpress plugins are .php files which are supposed to be copied into
the "/wordpress/wp_plugins" directory (and sometimes have a file in
"/wordpress" as well). Copying them into "/wordpress/wp_plugins" is no
problem but they have their own repository entries (eg.
svn:/repo/vendorDrop/wp_amazon/current) and manually copying destroys
this association.
Once a file has been copied from from a working copy of
"wp_amazon/current" into "/wordpress/wp_plugins" it:
1. loses any association with its original repo (and history).
2. becomes part of the main "repo/wordpress/current"
(instead of "/repo/vendorDrop/wp_amazon/current")
===> Other than checking out a dozen plugins to their own working copies
and then manually (or with scripts) copying the files (eg wp_amazon.php
--> wordpress/wp_plugins/), what other ways can this be automated?
If Subversion would let you could check out individual files these
problems wouldn't arise, but only being able to checkout folders makes
it more complicated. I know complete folders are much tidier generally,
but how do I handle a directory (wp_plugins) containing files of "mixed
heritage"?
I'd really appreciate some suggestions on how to organise thing so that
both the HTML, the PHP directories (eg. Wordpress and Gallery) can
maintained and updated individually, and the plugins can be managed. I'd
like to be able to try plugins and back out (sounds like a branch) or
update a plugin and maintain local mods, preferably without a lot of
manual intervention.
Thanks
Giovanni - www.reflections.co.nz
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 4 00:03:00 2005