On Mon, 2004-29-11 at 20:40 -0500, Tom Rawson wrote:
> On 29 Nov 2004 Patrick Smears wrote:
> >
> > The reason for the default behaviour is that any other behaviour tends to
> > confuse utilities like 'make' that depend on timestamps on files to
> > determine which file has been changed most recently (e.g. if someone else
> > commits a change to a file, then I do a 'make', then I update my WC to
> > pull in their change - I want the changed file to have the time of my
> > update, not the time of their commit or the time they changed the file, or
> > else 'make' won't know to rebuild targets that depended on the changed
> > file...). Since 'make'-like build systems are a very common use case for
> > Subversion, this is what the developers have implemented.
>
> Fair enough. The approach you described makes a lot of sense for a
> multiprogrammer C project. BUT the exact same requirement -- using
> timestamps to drive utilities that determine what files have been
> changed -- argues for the opposite approach when the code is not
> compiled and deployment uses the timestamps on the source code. In the
> projects for which I need Subversion right now, the code is all
> interpreted (PHP, JavaScript, HTML, CSS) and is deployed to the web.
> The deployment uses timestamps to determine what has changed since the
> last time the web server was updated.
I'm not sure what your term "deployment" means, but if you want to see
what has changed shouldn't that be subversions job?
Why not create a tag for every release you do to production and then do
a diff against the latest tag? This will show you what has changed and
will not be dependant on time stamps.
> I can see that if original timestamps that show "last modification" are
> preserved it breaks the make utilities -- but if they are not, it
> breaks timestamp-based deployment utilities for code that doesn't need
> a make step.
Ah, I get it! You have a tool that doesn't "deploy" files that haven't
changed. Do you _have_ to use that tool or can you do some scripting in
SVN to deploy changes into production?
> It's too bad there's no way to select this as an option -- it appears
> that it's going to make my use of Subversion a lot more difficult.
That's one point of view. But with come creative juices (mostly coffee)
you might be able to take out the middle man.
Cheers,
Chris
Received on Tue Nov 30 02:58:32 2004