"Svante Seleborg" <firstname.lastname@example.org> writes:
>> >> Merge is likely to cause conflicts in the new properties, is that
>> >> acceptable? Should Subversion automatically "resolve"
>> >> such conflicts?
>> > Conflict is naturally resolved by having the latest win.
>> I suspect the conflicts should be resolved, I'm not sure that
>> the latest is the natural choice.
> Could you elaborate on that, give an example where the latest is not the
> natural choice? (For the time-stamps obviously - not the contents).
The value of the timestamp property doesn't matter as far as the next
commit is concerned, only the presence of the property matters. If
you resolve conflicts to the latest time value that will probably
cause the properties to show up as modified in the status output, I
don't think that useful.
I suspect that merge should add/delete the property but should never
change its value.
>> >> If the user changes a file's timestamp but doesn't change
>> the text or
>> >> any properties, should Subversion detect that?
>> > Yes. In fact that's what it does today, no? It uses the
>> file-times on
>> > the client to detect any change, it does not run any diffs
>> or hashes
>> > on the sources to detect changes.
>> No, as I understand it, the current code does not detect such
>> timestamp changes, they do not show up in the status output,
>> and the only way to commit a timestamp change is to
>> explicitly propset.
> Just how does Subversion detect a modified file then? I don't believe that
> it scans through all files, comparing bit-by-bit or hashing. I supoose it
> stores the last-modified-time in the client-side mirror, and does a diff
> when the time-stamps differ. Correction, anyone?
Yes, Subversion does check timestamps to do the normal change
However the new code on the branch doesn't detect changes between the
new timestamp property and the filesystem timestamp, so "touch" won't
cause a file to appear as modified and commit won't work without an
explicit propset. The person that wrote the code seemed to think that
was acceptable, at least as a first cut.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Aug 19 20:29:51 2005