Web Development in WAMP. How to create a repository with multiple dispersed directories?

[Eric Siegerman]

On 04/06/2013 03:17 AM, Alex Arantes wrote:
 > wamp/www/projects/site_01 (all web pages and other files like css, 
js, images, etc)
 > wamp/www/projects/site_02
 > wamp/www_config/site_01 (all include and log files)
 > wamp/www_config/site_02
 >
 > 1 - Is it possible to create one repository encompassing 
"wamp/www/project/site_01" and "wamp/www_config/site_01" other than 
defining the root folder as "wamp" and excluding all other directories?

Not that I'm aware of.

I can think of two alternatives:
   - If you're on Vista or newer, use symbolic links:
       - put site 1's config directory physically under
         the project directory (e.g. in
         projects/site_01/www_config)
       - create a symlink at www_config/site_01, pointing to
         the directory where the config files really live

   - Failing that, you can use two repositories for each project
     -- one for each directory.  Tie the two together using any of
     several Hg extensions -- guestrepo is one, but there are
     others.  There's also the built-in subrepo functionality, but
     I don't recommend it -- it's listed as a "feature of last
     resort" for good reason :-/


 > 4 - Should/could I also add the DB folder? 
(wamp/bin/mysql/mysql5.5.20/data/site_01/) Is it possible/desirable? Any 
concerns?

That's the site's database, right?

There are two questions here:
   - Should you commit the data?
   - If so, how?

Whether to commit it a design decision you need to make, based on
what's in the database, and whether you consider it more
"code'ish" or "content'ish".

E.g. We use Hg to revision-control a couple of Wordpress sites.
For our purposes, we don't want most of the data in source
control -- we consider blog posts, user accounts, etc. to be
content, not code.  But Wordpress stores all of its configuration
settings in the database too, and we'd really love to
revision-control those (and deploy them automatically to
production along with code deployments), as they fundamentally
affect the operation of the site.

If you do decide you want to revision-control the data, though,
doing that by directly committing the database files is almost
certainly a really bad idea.  Databases are typically large,
binary files, and Mercurial doesn't handle those at all well.

Better would be to export the data into a more tractable (i.e.
text) form, e.g. using mysqldump, and revision-control that.
Make sure to use the appropriate options to ensure that you get a
consistent snapshot (Google "back up live mysql database").

Yes, this means running a command before you commit.  (Maybe you
could use a Mercurial hook to do that automatically.)  But you'd
have to do so even if you were committing the database's files
directly.  Actually it'd be worse:  you'd have to run a command
before the commit to flush and lock the database -- and another
one afterward to unlock it.

   - Eric