[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [DESIGN] mtime versioning - was: Getting Bug 1256 fixed

From: Giovanni Bajo <rasky_at_develer.com>
Date: 2005-11-28 13:58:49 CET

Ph. Marek <philipp.marek@bmlv.gv.at> wrote:

>> It's not clear to me whether "svn up -rN" should restore the modification
>> time of the files at that revision. If so, that would break a common
usage
>> pattern such as:
> ...
>> I took some time to search the archive for previous discussions about
mtime
>> versioning. After some reading, the only argument that convinced me is
that
>> of importing external trees.
> And every other usage which does not involve make, eg. documents.

Ah right. I never used Subversion for other kind of data, so this is why I'm
biased towards source code repositories.

>> In my mind, it would be "svn import" *only* to
>> remeber the mtime of the files being imported (at least by default), so
>> that it can be restored later. I still fail to see what's good in having
>> "svn commit" records and stores the mtime of each and every file.
> That's why my patch only stores for files _with svn:text-time set_. All
> others are treated as before.

Thus, are you proposing this property not to be added by default (unless one
modifies its own Subversion configuration file)? What if I want mtime stored
only for imported trees? Will the flag work also for directories?

>> Off the
>> top of my head, you will also have to fight endless trouble with
timezones,
>> DST, different time encoding in Windows and UNIX, and whatnot.
> If you take a look into the stored timestamps you'll see that they look
like
> this:
> 2005-11-21T06:51:45.000000Z
> i.e. are stored in a text-format, UTC. Resolution up to microseconds, all
> conversions are done by svn. Which trouble could there be?

I know there is a long-time bug with CVS and DST, but I don't remember the
details. Google brought up this link:
http://www.devguy.com/fp/cfgmgmt/cvs/#DST. I suggest the problem to be
investigated in detail so to find out if it can be avoided in SVN. There are
also other issues with the rouding of mtime on different filesystems (e.g.
when you store a file into a FAT-16 disk and you read the mtime back, it can
be modified by rounding). This can cause trouble too; eg. SVN might think
that the user modified the mtime of the file while it was just rounded by
the filesystem.

Anyway the issue is moot if this feature is opt-in rather than opt-out by
default. Personally, I would turn it manually on only on import.

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 14:00:29 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.