On Feb 17, 2007, at 11:58, Jan Hendrik wrote:
> Actually this is about what I usually do, only that I also work on
> this "special" WC. But that's not the problem: the editors set the
> mod timestamps appropriately, FTP client sees these files have a
> more recent date than their counterparts on the webserver, uploads
> them, and then sets local timestamps of just the uploaded files to
> the time they have got on the server. Thus still an even more
> recent time than SVN knows for them and SVN checks them
> dutifully and commits them as necessary. As long as things are
> done this way as suggested there isn't any issue with timestamps
> here.
>
> The issue only arises if I have to upload from another WC (e.g.
> "special" machine not available, urgent upload of some modification
> in another WC otherwise not ready for commit) and in such a case
> even a really special WC would not make a difference:
It has been said before and I'll say it again: there should be no
such thing as urgent modifications that must be uploaded to
production before they're committed. If they're ready to go to
production, then they are ready to be committed. Make it so that the
only way to deploy to the live server is to commit to the repository,
so that you have a record of the change in the repository. Yes, I
have worked for years on web projects. Yes, I know that the boss says
"just upload it real quick and fix it later." Make your
infrastructure so that it is *easier*, not harder, to deploy the
change using the repository. For example, like someone said, use a
post-commit hook to auto-update the live web site after a commit of a
particular branch (or the trunk if you like). Change the passwords on
the FTP server so that only the administrator knows it, and it's only
used by the post-commit hook. Prevent developers from uploading
directly via FTP or any means other than checking in to the repository.
> In that case as any other WC has timestamps like last commit or
> last checkout/update FTP would consider them all for upload. So it
> must be "teached" first, by resetting timestamps to webserver
> timestamps. FTP then still sees modified files based on filesize
> and as long as these are uploaded things get right for SVN again
> as FTP then sets timestamps of these files to upload time again
> (see above). If, however, such a file is not uploaded for any reason
> SVN will never ever consider it for commit until further modifications
> are done on it.
It sounds like you are clearly demonstrating the problems with your
setup: allowing multiple paths for things to go to the production
site is problematic. Using a working copy to upload to production
that is also your development working copy is problematic. In some
cases, more files than necessary get uploaded to production, wasting
time and bandwidth. In other cases, your FTP sync messes with your
local modification timestamps (which is broken by design because the
local files have not been modified, so their modification timestamp
should not be altered) and in some cases the modification timestamp
the FTP program sets your local files to is the same as the
unmodified version Subversion knows about, thereby making Subversion
think the file is not modified, even if you have made local changes.
(I hope I understood your situation correctly.)
All this should make it clear to you that the way you are trying to
do things is not a good way to do things. Dedicate a particular
working copy to the task of uploading to production, and do not use
that working copy to develop the code, and do not upload from any
other working copy. Or, even better, write a post-commit hook which
manages the upload for you. The post-commit hook is given the
revision number, and from that it can determine what files and
directories were modified, and then upload only those. No need for
FTP sync or rsync or any other such software, since the repository
already tells you what has changed.
> Sure, in all this the user has his hands in the game. But isn't that
> the way half of all bugs come to light, the user doing something the
> programmer has not thought of? As Jeff mentions himself solving
> this with touch has its own issues because of .svn directories.
> And touch is not readily available on Windows, the user needs to
> have a port of Unix tools or something more intelligent than
> Windows Explorer (like e.g. TotalCommander). OTOH a switch --
> ignore-timestamps would be available for all SVN users, most likely
> make it to checkbox option in the GUIs, and by this come to the
> eye of also less savvy users wondering why their files are not
> committed. Having SVN honoring mod times would help for most
> of the occasions described above, though not cover others like the
> file taken to the home box with the broken clock.
I don't think there's any need to consider machines with broken
clocks. First of all, the likelihood that you save a file on your
broken-clock machine and the modification time is exactly the same as
the last modification time of the file on the machine with the good
clock is very small. And secondly, protocols like NTP exist to
synchronize your clocks to within at most a couple seconds, which
would be perfectly sufficient. There is no reason not to use NTP, so
broken clocks are a moot point.
--
To reply to the mailing list, please use your mailer's Reply To All
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Feb 17 21:27:04 2007