Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as off-topic by gnat, MichaelT, Bart van Ingen Schenau, GlenH7, Robert Harvey Jan 28 at 0:00

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking us to recommend a tool, library or favorite off-site resource are off-topic for Programmers as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it." – gnat, MichaelT, Bart van Ingen Schenau, GlenH7, Robert Harvey
If this question can be reworded to fit the rules in the help center, please edit the question.

11  
It looks as if you want a backup system instead? –  Macke Nov 19 '11 at 9:54
2  
Have you considered running your web site under OS X on a Mac? Time Machine is perhaps the simplest backup solution currently available and makes it very easy to roll back if needed. –  user1249 Nov 19 '11 at 10:00
1  
If you are seriously interested in the topic, you should have a look at research in versioning file systems and in versioning databases, which go beyond version control systems for source code. –  Jakob Nov 19 '11 at 14:33
    
what's wrong about writing a bit of scripting to handle such things that the scm do not handle ? that way you get what you want AND get it under source control. –  Newtopian Nov 20 '11 at 4:10
add comment

5 Answers

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.

EDIT:

The fix I am using is (a) No version control at all, (b) The production site is the master site, (c) Archive every time anything changes, (d) The archive script removes junk like ACL, and (e) the install script fixes other junk like file permissions.

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.

But why hasn't anyone built a general system to do this?

Because it isn't needed if you use a version control system.

A version control system COULD track all this stuff, but none does.

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.

share|improve this answer
    
+1 for fleshing out reasons for why the question is wrong from the start. –  Macke Nov 19 '11 at 9:54
2  
+1 Nevertheless, it's good that the question has been asked so that others can benefit from your answer. –  LordScree Nov 19 '11 at 10:31
    
A version control system is supposed to give me the ability to say "OK, on this other computer over here, build me the site as of July 28th." Version control is more efficient than backups because it tracks changes. Otherwise, yes, a daily backup would do the job OK. –  Andy Canfield Nov 20 '11 at 7:11
    
Yes, the fix I am using is (a) No version control at all, (b) The production site is the master site, (c) Archive every time anything changes, (d) The archive script removes junk like ACL, and (e) the install script fixes other junk like file permissions. But why hasn't anyone built a general system to do this? A version control system COULD track all this stuff, but none does. –  Andy Canfield Nov 20 '11 at 7:16
    
+1: Great answer. I would however like to add that no version control system tracks that stuff because they COULDN'T. The permissions and usernames are host-specific and their format is system-specific; there is no way the tool could automatically port them over to different host, especially when it's different operating system. –  Jan Hudec Nov 23 '11 at 15:45
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.

share|improve this answer
    
This. The idea of having sources at all is that you can pull them out of your VCS and use them to build the finished product. –  Blrfl Nov 19 '11 at 14:28
add comment

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 :

  • all libraries that you app depends upon in source control
  • a build file that sets your environment
  • an instruction on the requirements of your environment (you don't want to put a sql server install in your source control)
share|improve this answer
add comment

I believe what you need in your case is a configuration management tool. The one that I've used is puppet.

Quoting you:

manage file/directory ownership, file/directory read & write access,

I have done that with one line (ensure user exists, ensure directory exists, etc)...

Access Control Lists,

If this is windows ACLs then there are specific CM tools for windows...

timestamps,

again the touch unix command in one line in a puppet script could do this for you.

database contents.

That's build in many frameworks, a cron job that ensures everything is there otherwise?

and external links.

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 :-).

share|improve this answer
    
I don't understand what you mean by "timestamps - again one unix command in one line in a puppet script could do this". On my site, to get the site version, it scans the whole sitetree and returns the date and time of the newest file. I want my version control "Checkout" to give the files the same timestamp as they had at checkin, not set as 'now'. How do you do that in one unix command? –  Andy Canfield Nov 20 '11 at 7:26
    
of course, you are looking for "touch", check this: en.wikipedia.org/wiki/Touch_(Unix) . Generally when checking out the now-time will be applied, but if for some reason you want a different timestamp this is how to do this. –  dimitris mistriotis Nov 20 '11 at 22:55
    
I actually liked the rationale of your question, you want to automate as much as possible, which is the "right way", you need some know-how on how to do it and what goes to VControl and what not. I wish more people in out industry were thinking alike... –  dimitris mistriotis Nov 20 '11 at 22:59
add comment

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.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.