Everything is a Freaking DNS problem

I already touched the topic in the previous article, but I've been wondering, how do you ideally manage say Perl or PHP code in a Large Environment.
As earlier noted I want a system to be reproducability under version control and I want to be able to identify the source of every single file on my system either as belonging to a package or being transferred there from my version control platform.

For the ease of reading let's say we stick to mass deploying PHP Code. Libraries most certainly belong to be in packages. One can disuss where your own code belings.
sTypically PHP code, html layout and Stylesheets are small files that are modified manually by a developer . Often really small changes are being made to those files.
These changes don't need to be recompiled in order to be used so shops that use this kind of code don't always have tradition of build and release management.

I`m thinking about abusing configuration management tools to manage code and just consider code as a configuration file.
Amongst the disadvantages of using these file based management tools , puppet/cfengine/yourpoison but it should be a tool that makes it as easy for you to update 1 file on 1 machine as 1 file on 2000 machines.

• Unclear file origin , you have no direct link anymore between the file and where it came from on the machine as it doesn't show up in a package list and rpm -qf doesn't help you either
• You need a tool , most people these days know either rpm or dpkg , either apt or yum, using a tool such as CFengine or Puppet makes it more complex for new people to step in.

The DisAdvantages of packaging code

• You have a less granular way of defining which files need to be modified, it's an all or nothing approach , however you can define how small your packages are
• You need a build framework to build the packages, off course this can be automated.

If you use tagging wisely you're sure that either way you know which version is on the production platform.
Most configuration management systems have features that allow you to verify if a file is changed or to to do a certain action after you update this so that's not an issue.
Is using a package per application really that much overhead ? If you already have the infrastructure in place to build your packages then what's the extra effort ?

I've used both approaches so far, a lot depends on the culture of the developers team and the already existing infrastructure.

So what's your opinion ?