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
