Bert Huijben wrote:
>>> Pardon me for being a bit dense. Do you mean that generated binaries
>>> (or binaries in general?) should not have the 'mtime' stored?
>> No ...
>> If you've got some source files, you *don't* want mtime stored for them,
> so
>> that "make" knows what to re-compile.
>> But if you want to keep the generated binaries (and especially if there's
>> some
>> 3rd party dependence, eg. on some DLLs), you *want* the mtime - because
>> that's
>> the easiest thing to compare over a phone line.
>
> I would suggest making it default *not* to store these timestamps.
>
> If we are going to store them by default, a new client will introduce this
> property everywhere (even on existing repositories). Users of older clients
> can then no longer merge new revisions because this property will always
> conflict with versions on another branch. (We can't learn 1.0-1.6 clients
> that they should always just replace the old property value, when we release
> 1.7/1.8)
That makes sense. So if the mtime (or whatever) property doesn't
already exist then ignore it. Then the property should only be
applied to newly added files/directories, right?
So commit w/ mtime property iff the mtime property exists in the
repository for that file/directory.
> We really need better property conflict resolving before I would enable such
> a change.
Meaning a new issue should be filed/or followed up (if filed)?
>
>> So it's entirely possible that some files shall have the mtime stored,
> while
>> others shouldn't.
>>
>> In my branch that was "solved" by the auto-props - I extended them to
> apply
>> to
>> directories, too (someway, don't remember now), so that for certain file-
>> (and
>> directory) specifications "svn:text-time" could be set to "yes" on "svn
> add";
>> this would automatically be changed to the correct value on commit.
>
> This would be a solution to the problem mentioned above: Only change it if
> the file needs the timestamp stored, just like svn:needs-lock.
> (In that case the user decided that it wants to break certain older client
> features)
As mentioned above, would a 'better property conflict resolution' be a
pre-requisite for this or is it given the auto-props (as extended by
Philipp) be sufficient enough?
Thanks
Edmund
Received on 2010-02-06 03:16:37 CET