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.
Oliver
---------------------------------------------------------------------
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