On Wed, Mar 14, 2012 at 9:00 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> On Wed, Mar 14, 2012 at 7:29 PM, Nico Kadel-Garcia <nkadel_at_gmail.com>
> wrote:
> > On Wed, Mar 14, 2012 at 9:33 AM, Qazwart <qazwart_at_gmail.com> wrote:
> >>
> >> What if you deliver your source code *outside* of your revision control
> >> system? This is quite common for open source projects. If I can't trust
> the
> >> build process to do a clean, I'm in trouble.
> >>
> > What if you don't use a build process? Just today, I deployed an
> > "/etc/yum.repos.d" directory under Subversion, using an "svn checkout
> > --force" command to put it under Subversion. This is certainly not under
> a
> > "build" process, and I would have *loved* to ahve an "svn clean"
> operation
>
> So that's what, 500 bytes total if you had just deleted the whole
> thing and checked it out clean?
>
> In this case, more like 4 K. But it also creates churn and would *break*
yum during that few moments of deletion and re-install, and it would alter
permissions, which is *another* set of issues.
I've actually had this happen in worse fashion in Nagios and httpd, were
configuration files are read out of a directory and any file called *.cfg
for Nagios and *.conf for HTTPD ae read. Debris files are a problem, and
easy for someone to leave behind. And re-deploying /etc/nagios is file
ownership sensitive: typically, the HTTP password file is kept in
/etc/nagios/passwd, and *THAT* needs to be legible to the "apache" user,
although the /etc/nagios directory needs to be legivle to the "nagios" user.
Re-deploy also requires network access. Whatever for? The local working
copy knows its expected state!
Received on 2012-03-15 02:57:57 CET