On 30 Nov 2004 Michael Stevens wrote:
> a) Every time you deploy, you checkout a new copy of your
> repository, and then FTP it to the server?
Well, I was considering something like that but I still don't have a
working repository, so we're not there yet. It's slightly complicated
by the existence of main development and bug fix branches, so sometimes
they will get merged and sometimes we'd just be deploying off the bug
fix branch. But I don't think that is material to your strategy.
> b) The FTP client is checking the timestamps on your fresh working
> copy, vs the timestamps on the server?
Yes. What happens is that the server timestamps are set on the upload
(though we could disable that) so the client sees everything that has
been modified since the last deployment as new. Truth is it is not
comparing "last content modification" dates but rather comparing "last
content modification" on the development system to "last upload" on the
server. I also sometimes have to adjust for timezone differences
(depending on the project and where the server is).
> c) The timestamps of the newly checked out repository are all newer
> than the timestamps on the server (being that the timestamps have
> all been set to what was recently checked out), so the entire working
> copy is being copied, rather than the changes?
Yes ... "would be" rather than "are" / "is", since it's not live yet.
> If that is the issue, then perhaps I can suggest a simple solution.
> Maintain a working copy of the repository (lets call this the
> staging copy), don't delete it when you've done deploying. Don't
> checkout a new copy each time. Rather, simply run 'svn update' on
> your staging copy. Only new files will be updated, so timestamps
> should only change on the files that have actually been updated.
> After that FTP your staging copy to your server.
OK, so I am still giving up having the timestamp match the content
modification, but at least I will have a timestamp that matches the
last update time instead of a checkout time. Right?
I like the solution, I have to sort out whether that's a good tradeoff
but it might be.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Nov 30 05:00:38 2004