maintaining a website Live Version with JS and CSS minified

I'm going to list several quick facts for better understanding of my goal.

Am developing a project, let's call it AAA:

• At my webserver (data center) I have the AAA SVN repository.
• At the same webserver I have a checkout version of AAA (the live version - public html)
• I have at home a second checkout where I develop the AAA project

Every new version I develop at home I commit changes to webserver and then update the live area.

Now I want to introduce minified JS and CSS versions.

After a little Google 开发者_如何转开发search the way to go is SVN hooks. pre-commit and post-commit hooks.

This is what I have in mind now:

• create a post-commit hook
• everytime I commit a new version the post-commit hook runs a script to:
  • SVN update the webserver live area
  • then replace all the .css and .js files with minified versions

This works OK for the first commit. At the second commit the live SVN update fails because .css ans .js are already modified (minified) from the first commit. conflicts.

SOLUTION:

1# Use SVN export instead of SVN update for the live version. This takes to long and have problems with deleted files, etc. Solution EXCLUDED.

2# Force SVN to update live AAA version and ignore changes (minified files from the previous revision). This solution makes sense to me but I didn't found a way to make SVN update ignoring the current changes (minified files). Is this possible with SVN? I tried SVN updade tf and not working.

3# Willing to ear your solution :)

Thanks for helping.

I do not know what your environment is, but you can take the approach used by the Capistrano deployment utility.

If your live/production environment supports soft/symbolic links (such as Linux) what you do is:

• Create 2 directories in your deployment path

  ~/path_to_site/current
  ~/path_to_site/releases
  

• Set ~/path_to_site/current to be the directory that is being served

• Perform an SVN export to the releases directory, e.g.

  ~/path_to_site/releases/mysite_1234567 (timestamp)
  

• After the export is complete, change the path of your soft link for current/ to point to the most recent release, e.g.

  ~/path_to_site/current -> ~/path_to_site/releases/mysite_1234567
  

The benefits of this approach are:

• Your site is unmodified during the export process. e.g., in your current process where you do an svn update, there is a point where your site is only partially updated. If someone were to visit your site right at that moment, who knows what they would get.
• Each updated version of the site is a 100% clean export. No messing with files that should have been deleted or changed files due to the minification process.
• You have a very easy mechanism to roll-back to a previous release -- simply point the current/ symbolic link back to the previous directoy in releases/
• In your current approach of doing an SVN update, you make publicly available all the .svn folders and information contained there-in, because they are side-by-side with your publicly available files. This means someone could get information about where your repository is located, etc. In general, it is bad practice to have anything but what you want people to actually be able to get to in your public folders.

Tools like Capistrano help automate processes like this, but are not required. Either way, something like this could be accomplished with a post-commit hook, depending on your environment.

It should also be noted that not all server configurations will allow you to use symbolic/soft links in the paths of the folders that are being served.

Checkout continuous integration tools like Hudson or Cruisecontrol. These tools have capability to monitor the repository at a specified frequency and will perform the desired task after the checkout. This might suite your need.

That's a good one. Exporting as version,i.e. appending a timestamp for example. Then controlling the live version with a symbolic link. I use linux so am OK.

In the meanwhile I found a work around to accomplish the 2# described at the first post:

First - CheckOut - use a svn checkout as the live version - then compress .js and .css files Second to N - Update - svn reverve to all .css and .js files - svn update - then compress .js and .css files

The svn reverse will eliminate the compress files in order to allow the svn update without conflicts.

This way is faster but I think I'll follow your approach.