(snip)
> So status will show some sort of "modified" indicator
> whenever the filesystem timestamp and the property timestamp
> don't match?
Not some sort of "modified" - just plain modified. Just as if you had indeed
modified the contents too. Generally speaking that is the current behavior.
If you modify the filesystem timestamp, it'll show up as modified until you
try to commit, at which time it'll decide there was no "real" change. The
proposed design would consider a timestamp change a "real" change all on
its own.
(snip)
> Does it show up as text modifed 'M ', property modifed ' M',
> or some other timestamp modified indicator?
I'd say "text modified 'M'"".
>
> If the text is modified then the timestamp is probably
> changed, does the timestamp modification still show up when
> the text modification gets shown?
It's all part of one single "changed state". There should be no fundamental
difference between the two.
> What happens if I modify the timestamp property so that it
> matches the modifed filesystem timestamp. Does that show up
> as a property modification? Does it also show up as a
> timestamp modification?
From my point of view, a modification of the timestamp propery is equivalent
to patching the text in the repository - i.e. a manual change outside of the
normal workings of the system. The effect would depend on in which direction
the change was made, i.e. back or forward in time.
> If the filesystem timestamp resolution match the timestamp
> property due to resolution does that show up as a timestamp
> modification? Does such a change get committed?
If Subversion cannot see the difference, there is effectively no difference.
No change is seen, no change is there to be committed.
Svante
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 19 22:44:39 2005