On Wednesday 14 February 2007 04:30, Jan Hendrik wrote:
> Concerning Re: Poor performance in windows. Sw
>
> Jeff Smith wrote on 13 Feb 2007, 13:53, at least in part:
> > Can you imagine the increased _drag___ if svn were supposed to
> > assume that every timestamp were meaningless, and have to compare
> > entire contents instead? That would be horrendous!
>
> Well, make it a case of --force switch as I said downwards of that
> or probably a second posting!
I agree with having an option, in order to "free the user from this
bondage we call computers"--imajeff (that quote is fairly new... from
a few seconds ago).
I made a similar suggestion regarding another issue (concerning
mixed-eol-style toleration), but some peolple have amazingly hard
heads, reasoning that it would be horrible to give me a liberating
option just because they might misuse it.
> > I say if you haven't got
> > valid timestamps (especially for large number of files), you
> > haven't got version control.
>
> Dunno what timestamps (any unchanged timestamp still is a valid
> timestamp if the filesystem is not broken) have to do with version
> control. I would rather having SVN optionally honoring last
> modified as timestamp for checkouts/updates instead of
> commit/checkout/update time anyway. Timestamps may not
> matter in C programming, with FTP synching they matter.
By "valid timestamp", I really meant a valid timestamp of last
modification. In many filesystems there certainly is another
timestamp which does not change when modified, but the modified one
is invalid if it does not show when last modified. Well, there should
be no argument there, but it should be obvious why a "mod" timestamp
is fundamental to knowing when a file has been changed to it can be
archived (hence the invention of version control). Think about the
original purpose of the "archive attribute" in DOS. It was meant as a
fast way to see what files had changed for the purpose of archiving.
It became useless when not every editor took care to set it when
modifying the file.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 19:07:10 2007