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

Re: Subversion Problem - How to save file modify time?

From: Oliver Betz <list_ob_at_gmx.net>
Date: Mon, 14 Jul 2008 18:05:11 +0200

John Peacock wrote:

>> But in many other cases, mtime is a _very valuable_ information and
>> shall be conserved. Photographs and DLLs are both examples where the
>> file creation occurs far from commit and therefore commit time isn't a
>> viable alternative.
>Photographs and DLL's typically have meta-data tags contained within the file so
>the information is not lost, just not as easily accessible as you might like.

for photographs, it's a real mess, especially handling timezone (and
DST) adjustments. I don't want to do this manually everytime after a
checkout, it's hard enough when I transfer the files from
FAT-something to a UTC based file system.

>> I also see that there are pitfalls, and I hope that the subversion
>> developers find a stable and useful solution.
>> BTW: I also wondered why there is "active resistance" against
>> preserving mtime.
>There isn't 'active resistence' but rather 'conservative caution'. There has
>not, to date, been a design proffered which preserves something like mtime
>without serious side effects. For example, because mtime is based on the client
>machine (as opposed to commit time, which is based on the server), if the client
>machines are not synchronized, the value is not meaningful. At the very least,
>mtime is much more prone to inconsistency among multiple machines because of
>this. Additionally, *everyone* who uses Subversion with a build tool like make,
>Ant, etc. will have their build process break completely if this feature gets
>turned on (even by accident).

You refuse the feature because it could harm if activated by accident?

Isn't the already available possibility to set the mtime to the
commit-time as dangerous?

This accident (rather hard to achieve) would break make for the
moment, but this would be easy to repair (rebuild / touch).

>If you or someone else who believes this is a vital feature can produce a design
>that would deal with these issues, even if you cannot code it yourself, I have

The "issues" you mentioned are minor. Bigger problems of mtime
versioning already have been discussed.

>no question that the feature will get added. But that hasn't happened yet, and

Philipp Marek comes to mind.

>until that happens, claims that the project is resisting this are just paranoia.
> In all of my years in the open source community, I can assure you that this is
>one of the most careful and considered projects I have ever seen. Every single
>feature is carefully considered before being added, and as such the project is
>extremely stable and consistent.

I appreciate this, but it doesn't change my impression.


To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-14 18:05:50 CEST

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

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