On Sat, 15 Sep 2007, Randal L. Schwartz wrote:
"david" == david <david@xxxxxxx> writes:
Why does everyone keep wanting "work dir == live dir". Ugh! The work dir is
the *source*... it gets *copied* into your live dir *somehow*. And *that* is
where the meta information needs to be. In that "somehow".
david> the problem is that at checkin you need to do the reverse process. the
david> other tools that you use on the system work on the live dir, not the
david> 'work dir', so it's only a 'work dir' in that git requires it as an
david> staging step between the repository and the place where it's going to
david> be used.
Eh? Are we still talking about a "website", or "/etc"? I'm talking about the
website case. I don't do *anything* to the live site. When I want to add a
file, I add it to my dev repo, possibly modifying my Makefile, and then spit
it out on my staging server. (You *do* have one of those, right?) Once I
know it's good, I push it to the live repo, and then "go live" with it. I
*never* work on the files that are the result of "make install".
even when working on a website it can be relavent.
yes, when you are developing html you want to do it on a test server ,
move it to staging, and then move to production. but it's also not
uncommon to have web based tools that allow other people to make some
changes as well (for example, a bank's website is mostly maintained by
their web development company, but the bank administraters want the
ability to change rate information instantly). sometimes this is
implemented by writing the info to a database and then querying that
database for every hit, but a far more efficiant way is to store that data
in a file on the webserver, which can include modifying pages directly.
but yes, I was mostly thinking of /etc instead of the webserver when I
wrote that.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
