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. | [reply] |
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.
| [reply] |