A few months ago I dug into Subversion and GIT and was disappointed. They handle SOURCE CODE fine but not other aspects. For example, a web site under version control needs to manage file/directory ownership, file/directory read & write access, Access Control Lists, timestamps, database contents. and external links. Is there a version control system that can do as perfect a reversion as reloading from a month-old backup?
You are confused about the role of a version control system. It is not and never was intended to be a backup system for a running web site. It does an extremely good job of managing static content so that it moved into production in a controlled manner. With proper use of tagging and automated checkouts, even fast changing sites can be kept in a version control system.
A version control system will be able to tell you how you got from what the site looked like last month to what it looks like today (at least for those components that are under source control). It should include everything you need to rebuild the website (excluding dynamic content). As other have noted, any changes to permissions and ownership should be scripted, and that script included in version control.
Access permissions for web sites are typically quite simple. (Basically, you need to ensure that the webserver can read all content and write very little of it.) With the exception of directory ownership of the few directories that need to be writable by the web-server subversion, and possibly git, can certainly handle permissions. Directories which are writable by the web-server typically contain dynamic content (created and updated from the web-site), which is managed separately from the web-sites source.
If I were ask to work with a web-site with complicated permissions and ACLs on your web-site, I would have serious concerns about the process used to manage the web-site. Implementing a version control system and moving the ACLs to it would be one of the solutions I would seriously consider.
Dynamic content, such as blog entries or comments, is typically contained in a database or other datastore rather than the version control used to build the site. The data store may be arranged to provide version control of it content (as is this software). Many Wikis use a version control system to track revisions.
These problems can be handled by importing the site into a version control system and changing your process so that the master site is updated through that system. (a), (b), and (c) are handled directly by version control. You may want to tag releases to make (c) work better. (d) generally isn't an issue if you only have the deployment system changing your site. I have never needed ACLs on the site content.
(e) should only need to be run on initial creation and major changes. It might also include the script that updates the site from version control and runs frequently. These scripts tend to be quite simple when you keep you site in aversion control system.
Because it isn't needed if you use a version control system.
Both CVS and Subversion track what you need to track if you are using them. They won't track the thing you need to track because you are not using a version control system, nor should they. They track what you need to track when you are using a version control system.
I've worked with several sites that managed their content using version control. All had different requirements for staging sites, deployment frequency, and completeness of updates. Once the sites were in version control meeting the rest of the requirements were relatively easy to meet. Documentation for both CVS and Subversion make suggestions for possible update methods.
You may need ACLs to limit access to particular areas within the version controlled content. However, I tend to work on a trust basis. Version control makes it easy to see who did what when. If you don't reformat files it is easy to get an annotated history of a file showing who added which lines when.
|show 1 more comment|
All of them and none of them.
It is a bad idea to get source control to manage those details directly, in the way your question intimates.
However, you can write a bash script (*nix) or powershell script (Windows), which achieves any or all of those goals. This script could be stored in source control.
Then you can make that script one of your build artefacts and run it as part of your deployment.
IMHO a version control system in itself is not intended to be used in that way.
But what I tend to do is to make sure that you can get a version from source control you only need to run one build file/powershell file and everything is up and running again.
For this you need to :
I have done that with one line (ensure user exists, ensure directory exists, etc)...
If this is windows ACLs then there are specific CM tools for windows...
again the touch unix command in one line in a puppet script could do this for you.
That's build in many frameworks, a cron job that ensures everything is there otherwise?
Do not know anything about that.
Of course after you write your Configuration Management code, you might want to put it (or retrieve it in the systems involved) on a version control system. You will not get away from those :-).
There is an ultimate version control system that manages all aspects of all digital documents. It's called Xanadu and was created by Theodor Holm Nelson in 1960, even before things like file systems were common. So in theory everything is perfectly solved. In practice, Xanadu has never been implemented as envisioned by Nelson, but it inspired many more specialized systems, including the Web and version control systems. Nelson's works are still worth a fresh read - and they may answer the question why there is no general VCS that manages all aspects.