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,
>> that "make" knows what to re-compile.
>> But if you want to keep the generated binaries (and especially if there's
>> 3rd party dependence, eg. on some DLLs), you *want* the mtime - because
>> 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
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,
>> others shouldn't.
>> In my branch that was "solved" by the auto-props - I extended them to
>> directories, too (someway, don't remember now), so that for certain file-
>> directory) specifications "svn:text-time" could be set to "yes" on "svn
>> 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
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?
Received on 2010-02-06 03:16:37 CET