Lets say you have a code promotion hierarchy consisting of several environments, (the polar end) two of which are development (dev) and production (prod).

Lets say you also have a web application where important (but not developer controlled) files are created (and perhaps altered) in the production environment.

Lets say that you (or someone above you) decided that the files which are controlled/created/altered/deleted in the production environment needed to go into the repository.

Which of the following two sets of practice / approaches do you find best:

  1. Committing these non-developed file modifications made in the production environment so that the repository resembles the production environment as closely and as often as possible.

  2. Generally ignoring the non-developed production environment alterations, placing confidence in backups to restore the production environment should it be harmed, and keeping a resolution to avoid pushing developments through the promotion hierarchy in the reverse direction (avoiding pushing from prod to dev), only committing the files found in the production environment if they were absolutely necessary in other environments for development.

So, 1 or 2, and why?

PS - I am currently slightly biased toward maintaining production environment to repository resemblance (option 1), but I keep an open mind and would accept an answer supporting either.

  • 6
    This looks like a really interesting question. Too bad I have absolutely no idea what you are asking. Maybe I need another cup of coffee. Commented Jun 19, 2012 at 22:42
  • @Robert Harvey - I could have probably given a more concrete example, but if something specific does not make sense let me know. This is a best-practices type of question so it was a little difficult to explain/ask.
    – ghbarratt
    Commented Jun 19, 2012 at 22:46
  • @ghbarratt: I think it's mostly your title that's hard to get by, but granted I also need coffee (or may just be clueless).
    – haylem
    Commented Jun 20, 2012 at 15:57
  • I really appreciate the 3 great answers given.
    – ghbarratt
    Commented Jul 3, 2012 at 14:44

3 Answers 3


If the application is creating its own files, separate from those the developers create, you are essentially talking about using your development source control as a backup system. There are no advantages over any other kind of backup system and you're allowing files to be edited by people who don't understand source control. This seems dangerous to me.

Now that doesn't mean that you shouldn't take a copy of these files every now and then and deploy them to dev, just to keep the systems in sync, so that your tests are a more valid reproduction of production. Just don't do that through source control and your normal build process. If you did then what would happen if you start a build and then the application edits a file that is then overwritten by the deployment?

Another option, of course, is to put them in their own source control and give bi-directional control to the application (in essence, use VCS as a database for your application). This way you can handle revision history and such without having it all mixed up with the developers' changes. DVCS would be good for this, so that you can make changes on one environment and then push them to another -- perhaps even have a content-test environment where you can make changes, test them, then push them to both production and the application-test environment.

Even if the files edited by the application are the same files edited by developers, and thus they need to be merged, if the files are binary and edited often, I'd have to think very hard about the consequences with respect to the size of my source control database.

If they were text then fair enough but, unless I was very sure of the people making changes, I would again want to use a DVCS and make sure the application commits to a clone of the database, just so that I can pull them to a developer's machine and check them before committing to the master build database.

  • So your answer is neither 1 or 2, but rather you are recommending to separate these production/application controlled files from the (developer developed) files in the normal repository?
    – ghbarratt
    Commented Jun 20, 2012 at 13:33
  • @ghbarratt: I'm suggesting several approaches, depending on your needs. But yes, that is one of them, and probably the best one based on what you've said so far.
    – pdr
    Commented Jun 20, 2012 at 13:40
  • Well, as you suspect, my question reflects a real-world situation. I will attempt to make a stronger case for considering separating these files out, but I was wondering (and what I tried to ask with my question was) what approach would be best if that decision was not an option, or rather that the decision to place these files in the repo was already made and not available for reconsideration. I agree that separating these files from the repo could be the best approach in our real-world case. I am just not sure if I can even consider it, but I hope to give it a vigorous attempt. Thanks
    – ghbarratt
    Commented Jun 20, 2012 at 14:50
  • @ghbarratt: Well, if it's really not a choice then focus on my last paragraph - make the case for a DVCS and manual pushing to the dev branch. And then cross your fingers, or some other superstitious approach.
    – pdr
    Commented Jun 20, 2012 at 15:05

I'll go with "Save early, save often." Or, in this case, "Commit early, commit often."

Your #1 approach seems sensible, provided you get the granularity right. In any coding context, check-ins are done when they makes sense. It may not make sense to create six new control revisions for minor spelling errors, in the name of near-real-time fidelity.

On the other hand, your #2 approach seems destined to fail, if for no other reason than it has the words "confidence in backups" in it. [shudder] It also seems to run afoul of the decision-maker's instincts to put these files into source control in the first place.


I would go with option 2.

Separation of concerns makes me think that features and functionality should be as independent of content as possible.

Also backups are for restoring an environment into a production state, ie a harddrive dies ect.. If the backup is the development environment (or even test/staging) and someone has committed a half baked feature.. you can not restore your production environment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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