Concerning Re: Poor performance in windows. Sw
Ryan Schmidt wrote on 17 Feb 2007, 14:26, at least in part:
> 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
I'm the boss - but so are the others here, too! Only that I'm the
only guy setting up computers and finding & installing new
software/solutions while the rest of us just uses stuff to do work, in
some respect like kind of trained seals ... At times it is hard to
train them while I myself still need training, not even being a good
instructor... <GG>
> 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.
That would be a more perfect world, at least as the pitfalls come up
later only ;) and with the suggestions of all of you we certainly will
at least get a step or two closer overhere, though for the time being
most likely not as perfect as the suggestions would allow.
> 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.
Something I already have thought about, though there are pitfalls.
> 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.
Oh come on, Ryan, way back when I started using SVN and
growing many a grey hair following it through all the alpha versions
from 0.27 till 1.0 when I abandoned it for not not committing files
(probably for the very same reason, the only thing I can say about
it today is that that WC was definitely not used for FTP sync as
that machine could not even connect to the web then; re-entered
SVN at 1.3 for another try only) I read a lot about SVN going to the
moon to save the user's data, and here I happen to come over a
trap for data loss and you practically say the user has to go to the
moon to make sure it does not happen. Sure, no program can
handle every possible failure, that would be the egg-laying
woolmilksow bred into a perpetuum mobile, but even FTP is
smarter than SVN, comparing *both* timestamp *and* filesize
before making a decision. Someone absolutely correctly said that
timestamp-only based synching is dangerous, but SVN just does
that, without even a fallback option.
I dare saying there are many smaller LANs out there not set up to
sync clocks with NTP. Or at least to sync between each other
(following several instructions I still failed to even make this work
within an all-W2K LAN). And even less home LANs or single home
computers (said taking home a file for after hours work and copying
it back into WC the other day). Besides NTP mostly is for
machines permanently connected, not for dial-up. However, some
20-30 km out of town you are mostly out of luck overhere
(Germany, probably most of Europe as well), and with the
telephone comps already going for next-generation broadband it is
debatable that wimax will have much of an impact, not because of
lack of people needing it, but lack of investment money and lack of
content useful for not-so-fast broadband anymore. 20km from the
next greater towns we were lucky enough only two years ago
getting one of but a few snail DSL slots here. And in another
besides for the mainline user in Windows NTP is practically
inexistent as not available through the system panel or other GUI
place as long as the user does not go for external tools.
OK, I understand that in spite of all your efforts to help me getting
around this - for which I am very grateful and there will be
improvements on our side - this thing is not seen as an issue of
SVN or at least not of any priority beyond my very special case.
Actually I did not bring it up as an issue of its own either, making
just an aside to some suggestions for the OP's performance
issue... <g> That also files with different filesize are affected I did
not even know then...
A fine Sunday to all of you!
JH
---------------------------------------
Freedom quote:
Freedom is not created by government
nor is it a gift from those in political power.
It is, in fact, secured more than anything else
by limitations placed on those in government.
-- Ronald Reagan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Feb 18 14:22:55 2007