Concerning Re: Poor performance in windows. Sw
Jeff Smith wrote on 15 Feb 2007, 10:01, at least in part:
> On Thursday 15 February 2007 04:45, Jan Hendrik wrote:
> > FTP synching e.g. Not everyone has his own live server standing in
> > the own basement and not every hoster provides SVN to make the live
> > copy just another WC. As long as _always_ done from the same WC
> > there's no issue, but the moment you do it from a
> [...]
>
> My first thought was, what does FTP synching have to do with
> Subversion? Do you mean that this is where you are getting your
> timestamps messed up, and that's why you need a "--ignore-timestamp"
> option? In that case I agree, the option is needed for quick
> workarounds. At the same time, it would not be a solution to the
> problem. I'd suggest fixing your messed-up FTP sync.
Think I mentioned in a previous posting how I happened to get into
the timestamp trap, but here step by step (please accept my
appologies for this becoming lengthier):
1) Web site, approx. 10K files content (HTML & JPG; semi-static,
actually PHP, headers, footers, etc. included. Running this out of
a database is something I would rather not for a couple of reasons,
this as a sidenote)
2) The files are worked on on a small LAN, three machines (W2K),
four WCs.
3) The repository is on one of the machines on the LAN, no access
from outside (as much as I hope! <GG>)
4) The webspace is hosted outside. Access: telnet, SSH, FTP
5) Files are uploaded to the webserver through FTP using one of
the WCs as local source. Long ago we used WS-FTP, then
changed to Total Commander. AFAICT they both work the same:
compare local & remote folder trees by checking timestamps &
filesize, indicating files that are different in either one or both. Now
in synch mode local files are uploaded, then *local* timestamps
are set to *remote* timestamps so the next run these files would
not be listed for upload again. AFAIK this is the way FTP works -
the files are not copied, but their content written into a (new) file on
the target.
So far FTP synching has nothing to do with and does not interfere
with version control. That synching changes the local timestamps
results in some performance penalty with SVN for the respective
WC, but running TSVN cleanup now and then takes care of this.
Though it involves some manual activity the whole process leaves
the control to me - files can be excluded at will, files generated on
the web server can be taken care of, and I can see immediately if
something has not worked correctly.
The point, however, is that *all* FTP synching has to done from the
*same* WC - all the other WCs have timestamps different from
those on the webserver (checkout/commit time).
So if for any reason an FTP synch is to be done from another WC
local timestamps first have to be adjusted to remote timestamps or
FTP synch would consider *all* files as modified. Afterwards FTP
will still indicate files that are different (more exactly: that have a
different filesize), but SVN will not commit any file anymore that
was not committed before FTP synch, no matter if the filesize had
changed or not (the typo thing where filesize does not change
either is a special case).
So not FTP synch is messed up, it's that SVN and FTP synch
don't go together too well. We could leave it at that if we had not
found several other cases timestamps can get mixed up to a point
SVN ignores modified files (and thus risks losing data). Neither
would it be a good argument to say Then use something else than
FTP. No application should limit one's choice for the rest of
programs in the whole workflow (remember the Trash your editor
argument in the mixed-EOL thread?) beyond cases of severe
inevitable interference.
> It might help to know how to use Subversion appropriately to sync your
> personal repository with another. Speaking from experience, you don't
> need a separate server in your basement, honest. Any PC these days is
> a PS (Personal Server), even the same one you do work on.
In the case here it's not about synching two repositories. It's just
about keeping a remote webserver in synch with the local copy that
is an SVN WC while the remote one is not and cannot be (neither
is SVN setup on the webserver nor do I have the option to set it up
there nor would I want to do so just for the hassle of opening a LAN
to remote access not needed for anything else).
> > > What about comparing timestamps and filesize - if either differ
> > > then the file must be a candidate yeah? I know this is still a
> > > long way from perfect, but it would cover most of the cases that
> > > people are concerned about.
> >
> > Would not catch the corrected typo issue though it might serve for
> > general purpose without much (if any) of a performance penalty while
> > significantly enhancing SVN's guessing about a file being modified
> > or not. Anyway, if something like the proposed is done at at all I
> > think a switch option that takes *all* guessing out of it would be
> > by far easier - and serving the purpose much better.
> >
> > JH
>
> "corrected typo"... CORRECT TYPO?? So you're the culprit! Correcting
> a typo is definately changing content. Honestly, how can you claim
> that ANY type of search&replace operations could justify preserving
> the mod timestamp!?
Alright. How I happened to come about this I have tried to explain
above. We had some other considerations about how this situation
can happen (taking a file - not the WC - to another machine with a
clock off synch and copying it back into one's WC the other day
e.g.) and I also have seen and probably used in the past tools for
S&R with the explicit option to preserve timestamps, whatever the
use or idea of this may be. Certainly one can argue that taking a
file out of a WC for homework on a machine with a clock out of
synch and putting the file back into the WC on Monday is a user
error - the user should have checked the clock, the timestamps,
downloaded 100MB WC to his home machine, should not use a
legitimate *nix command like touch, etc. etc., but finally computers
and applications shall work without the user having to go to the
moon, shouldn't they?
Sorry that this has grown that much out of what was just a side-
note, didn't intend to spend so much time on it either. For me it is
an annoyance I usually can work around by strictly using one and
only one specific WC for webserver synching. Nevertheless it
reveals kind of weakness or flaw in SVN, a hole where data loss
can happen, and it would be nice if this could be closed by the
suggested switch. Personally much more annoying that I had to
take Python code out of versioning because of SVN not merging it,
but creating conflicts where no conflicts were. That is a different
issue, however.
JH
---------------------------------------
Freedom quote:
Intellect annuls Fate. So far as a man thinks, he is free ...
The revelation of Thought takes man out of servitude into freedom.
-- Ralph Waldo Emerson, Fate
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 15 23:07:02 2007