Hello, just thought I'd jump in here... Am I right in assuming that:
a) Every time you deploy, you checkout a new copy of your repository,
and then FTP it to the server?
b) The FTP client is checking the timestamps on your fresh working
copy, vs the timestamps on the server?
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?
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.
We use this exact solution here at work (albiet with a complex file
comparision tool someone hacked up in Perl, rather than a simple FTP
client), and it works just fine.
On Mon, 29 Nov 2004 21:55:02 -0500, trlists@clayst.com
<trlists@clayst.com> wrote:
> On 29 Nov 2004 Christopher Ness wrote:
>
> > Ah, I get it! You have a tool that doesn't "deploy" files that haven't
> > changed.
>
> Yes. AN FTP client, in this case. It's a simple process.
>
> > Do you _have_ to use that tool or can you do some scripting in SVN to
> > deploy changes into production?
>
> Well yes, but I'd rather not! I'm also used to simply observing the
> timestamps (as in "well, I probably don't have to check there to see if
> that's where the newly created problem is, because that file hasn't
> changed since last July"). I shouldn't be reworking my whole work
> environment to meet the needs of the VCS -- it should be a tool, not a
> framework that defines the development setup (though these days, many
> of the tools behave like wannbe frameworks! :-)).
>
> > > 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.
>
> The FTP client isn't a "middle man" it's a tool appropriate for the
> job. One of the things I like about Subversion is that it doesn't try
> to be something more than a VCS -- but I wish (based on admittedly very
> limited experience) that it didn't make quite so many assumptions about
> how VCS users operate. Of course it has to make some -- I just want
> the ones that don't work for *me* left out :-).
>
>
>
> --
> Tom
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 30 04:38:00 2004