Best way to use svn for web development

Question

Hello,

I installed svn on my server and am wondering whats the best way to use it. For example I have apache folders of htdocs and cgi-bin. Should I put both the folders in svn? when i work on a project i usually have the project_name as the folder in each - htdocs/projname and cgi-bin/projname? Should i svn both? Is it a good idea svning my images and other stuff from htdocs or should i svn only my code?

Also, is it worth svning word documents, psd files (which are huge normally like 100mb or so)? Or should i avoid them?

I am already doing daily incremental backup of all my data.

What do you think is the best strategy a small web development company should adopt?

Thank you very much for your time.

Answer 1

SVN is a version control system. It may sound silly, but you should use it for anything that you want versioned. Its common practice to have all of your code base that you actively work on inside of a SVN repository.

This isn't set in stone however - you can put anything you would like in there. It is just meant to store versions of code such that if you'd like to go back and restore an earlier copy of a file (of any type), you can.

Hope that gives you a general idea,

Answer 2

If you are checking out your project from Subversion on your server to deploy it, then you probably want them under the same umbrella project.

You should consider using a deployment script (Ant, Rake, Perl) to automatically SCP/FTP your changes up from your development machine instead of checking out from Subversion on the server.

You should version anything you need to re-create your site and anything that's important to the site - that would include site images, CSS, JavaScript

If you for see having a lot of large binary documents and don't want them filling up your repository you could consider putting them in a separate folder and set Subversion to ignore that folder.

Answer 3

I would say that in most cases, you want to SVN everything that makes your project what it is at a given version. Always include sources of everything to be able to regenerate your project exactly as it was. You probably won't want the compiled version of your app because you'll easily be able to get them back from the sources themselves.

Also include binaries (such as images) that are dependencies and that you don't want to or can't regenerate from hand easily. For example, don't put a hundred PSD because it might be long to regenerate the exact indexed GIF out of them. But you'll probably want to include your PSD in addition to the GIF. Include DLL of bought proprietary libraries and so on... Finally, I'd say to also throw in any configuration files that make the application behave as it is: Apache vhost, .htaccess, php.ini, etc.

I think the secret is really to be a close as possible to one or two clicks away of testing a prior version. The additional backups are great (and you should also backup your SVN repository) but you don't want to recreate from memory what version 6 looked like from the modification dates of the files in your backup folder.

Answer 4

I version control everything that may change. For me this includes:

• Code
• web content (html and images)
• Third party libraries (imported .jar files)
• Documents
• Server Configuration files
• Even the deployment scripts themselves (ANT and .bat)

I prefer a folder for the "project" with sub-folders for each type of content. That way if I'm only editing code I don't have to check out the large documents folder.

Use whatever structure works for you but don't loose a record of your changes as it can save your @$$ to be able to back out a change or resurrect a document you thought was no longer of use.

Answer 5

I put everything into version control that a programmer would need. Now your case that might require the word docs and psd files. In my experience word docs are normally created by (and for) the project management and I actually wound up setting up a document repository for that (we used Knowledge Tree). For the graphic source files I would recommend either a separate repository or at least a different project so that you don't need to include anthying that is not necessary to the development/deployment of your app.

The one thing I often see overlooked is configuration scripts. Obviously you will want to be careful about keeping production passwords out, but you will want examples and plain text instructions so that any IT tech should be able to figure out how to set things up. But make sure you have config files for your app, apache, database--all of the parts.

The single biggest help to our deployment was adopting a fully automated system to deploy our servers. For rails we use the fantastic Capistrano, and for windows we rolled our own using svn and python. I don't really recomend rolling your own, it takes alot of time and efort. However it has saved us much in the end.

Even if you don't use Rails I would suggest doing some research into how Capistrano works, it works well, and has solved alot of the problems we were dealing with.

Answer 6

There are several web development issues for which svn is a good one-stop solution:

1: versioning: svn maintains past versions as save sets, i.e. each commit gets its own reference ID that covers all the files updated in that commit. Used carefully, this lets you monitor all the files that get touched by a bug fix, for example, something that cvs lost.

2: easy branching: this allows you to work on a new feature alongside the on-going maintainence work without breaking the shipping system, then merge the new stuff back into the main trunk once fully tested. Even for a one-programmer shop this is worth the investment in getting svn up and running. First you do not lose the previously working system, second moving between that and the new development is almost trivially easy vs archiving full product trees, third your client experience is not corrupted by development iterations, and fourth this can be used to sand-box concurrent work by multiple programmers.

3: do not confuse svn versioning with archiving. They are very different things. Include your svn repository in your standard archiving / backup regimen.

4: svn knows how to keep deltas for binary files, unlike older systems like cvs, so keeping everything on your project under svn is worth doing. Keep the svn tree the same as your product delivery, then deploying is simply a matter of ssh to your site server and running svn update in the html and cgi-bin folders (make sure Apache is configured to deny all to the .svn management folders).

5: databases are a slightly less integrated issue, but keep a part of your tree for db export archives.

6: now when you need to re-create a past state, for whatever reason, all the needed tools and other files should help to do this. Note that svn does not inherently solve the fragmented repository issue completely: html/, cgi-bin-/, and db states, are disjoint and need manual correlating, unless you keep them together under an umbrella folder.

7: you'll need apache2 and openSSL and a valid certificate to go with svn on your svn server. You probably already have that sionce you already did an install.

If you have had even one bad client experience from work in progress files escaping to the live site, then a good svn regimen would have paid for itself in preventing just that. Most IDE's and editors also include svn management tools so you do not necessarily have to exit to command line. There are also OS X Finder and Windows Explorer plug-ins from http://www.tigris.org/ (amongst many other great tools).

Answer 7

• Remember that Subversion isn't just for backing up files, it's for recording a snapshot of the environment at various points in time, so you can restore to a previous state if need be. So if you need it, and it ever changes, then it should be in Subversion (unless it's a file generated from other files in Subversion).

• For a normal software project, it's common to have /trunk/ and /releases/ directories. For web projects, I like to have a /devel/ and a /live/ directories, with a /docroot/ directory under each, which holds the contents of the web server's DocumentRoot. All files not for publishing (working files, source code, programs, etc) go outside of /docroot/.

• To publish the work from Subversion to the web server, use "svn export http://url/live/docroot /path/to/web/docroot", which will dump all files (without the .svn directories).

• All work gets done under the /devel/ directory. When you're happy with the changes (hopefully you have a place to internally publish the devel site for testing), use "svn merge" to copy the changes over from the devel repository to the live repository.

Answer 8

thank you for all your answers.

spilth you have mentioned using a Perl script to help checkout data onto the live server. How do I achieve that? Any guidelines? This is how haphazard my development is now:-

1. I start off with creating some PSD files as design.
2. Then i slowly convert them into html+images and place them in my apache/htdocs/projname/images folder
3. then i add the perl script in cgi-bin folder
4. then i add other relevant music/css/js files in the htdocs folder
5. Once it looks fine on my local apache i upload it using ftp on to the live server and modify the shebang line (cause i use windows on my computer)
6. Then, when the client asks for changes i make them directly using ftp (i right click and edit the scripts on the live server)
7. Thus my version on my local computer is outdated.
8. Thus my development is completely hap hazard.

Also, I need a way to manage my mess. Cause this is not working too well as you can see. Also, if i checkout directly to the live server, what about the changes that the client might have made to the files? Will they get overwritten and lost?

Thank you, As you can see, I am very new to SVN. Currently am doing pretty badly in managing all this and I hope to improve this with your help.

Also, I want to know the difference between trunks/roots/branches/tags. Do I need all of those?

Thank you

Answer 9

First of all, try to understand the concepts behind version control systems and the workflows attached to it (import, checkout, commit, update). Especially how to integrate them in your development and deployment process. Here is a very simple example workflow (for simplicity, a non automated deployment process):

1. Import your project files into a subversion repository
2. Checkout a working copy on your development machine
3. Make changes and commit them
4. Have a working copy (svn checkout) on your server. Ideally, you have ssh access to your server, so you can issue this commands on the server. For that to work, your svn repository must be accessible from your server (e.g setup an svn server via http or svn protocol). If you don't have ssh access, just upload an svn export via ftp.
5. Update the files on your server (svn update or ftp upload)

As for trunk, branches and tags: These are just folders in your svn repository that you have to create if you want to follow the conventions:

• trunk: Development version
• branches: Releases e.g STABLE-1.0. Your production server normally runs on a working copy of a release branch
• tags: Certain milestones in the development history

For instance, you can create a release branche vor version 1 stable, by creating a folder STABLE-1.0 inside branches and copy your files into it.

Once you have established a development process, automate it using whatever tool fits you such as shellscripts, ant, capistrano etc. because a manual deployment process is error prone.

There is a very good book about subversion and the concepts behind it from the pragmatic programmers called "Pragmatic Version Control using Subversion" (http://www.pragprog.com/titles/svn/pragmatic-version-control-using-subversion).