Excellent point, one that I had factored out of the posted questions in an attempt to simplify the discussion.

The current plan is to treat the entire site as a development project, with server configuration, page development, client scripting, and server scripting as a single project. Thus, the "root" folder gets version controlled.

While there may be some disagreement on that approach, I believe that treating each element as part of the whole helps ensure the end results are closer to what the user asked for...and not what we chose to give them... ;-)

Several thoughts.

How much data do you have? One nice thing about CVS is being able to check out many copies at once. This gets very prohibitive on disk space.

How fast does it change? Remember that CVS archives the entire history of files. If your data changes fairly often, this archive can get huge.

When everything is released, do you want the release schedule for the website to be tied to the refresh of your data? I would guess not. If you don't then you don't want the data to be mingled in with the code versioning system. If you do, that is a big restriction that you should be clear about up front.

Speaking of which, your current development environment will be your default maintainance environment. Stop and think about that in solving these configuration questions. You are likely to live with this solution in other phases of your project and your answer should remain good.

For these and other reasons I would suggest that you use some sort of standard incremental backup system for your data files, and not have data in your version control system. Otherwise you are imposing several subtle restrictions on your clients. If they want to basically have a static, "About us" home page, the restrictions will not matter. If they want to have things like bulletin boards, news articles, file downloads, etc then the restrictions will likely turn out to be unacceptable.

tilly,

Well, you're bringing a number of excellent issues, none of which I had planned to address at this point. C'est le guerre.

Data is minimal at this point; disk space isn't.

While I am not the _owner_, per se, I am co-administrator, so I have as much physical resources as I need...for testing. In production, otoh, I have zilch, squat, nada. I am the lone gunman. Mulder has Frohike, Langley, and Beyers. I'm expected to serve as all three. (Isn't that a weird thought?)

Changes do not currently happen very quickly. I'm taking advantage of this to learn the best practices, thus leading to my continued and un-ending questions on the subject. Please note that *_DATA_* currently enjoys a strong demarcation (as well as separate backup process). In my examples, please assume that \data refers to some other, external data source with a strategic and complete backup process administered by someone else (as well as my own TRUSTNO1 backups).

Your points are well taken, though, and I appreciate all of them. As soon as I have some votes...

What I'm really worried about the security issues that I haven't *_seen_*. I hope others will forgive me, but merlyn was quite adamant. Assuming that he's correct, that gives me pause. I know I can't make my system 100% secure, however, I want to exercise all due caution in my implementation _and_ make d@mn sure I don't leave an exploit open. I can't personally afford the mistake.