(snip)
> >> >> 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.
Not sure if I understand all the implications, but if we regard the
timestamp property on equal footing with other metadata such as the file
name, I'd say that a change in the time value should indeed show as modified
in the status output. It's kind of an artificial case, but "touch" is such
an example.
>
> >> >> 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
> detection.
>
> 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.
What is "the new code" - are you referring to Ph. Mareks code, or someone
elses code that does implement some kind of time stamp preserveration? I
haven't seen that code, and this discussion was initiated since apparently
no design discussion had been undertaken on this issue.
My proposed design would indeed detect changes betwen the timestamp and the
corresponding property, and would indeed allow a commit after a "touch".
It's the whole point - file modification times are an integral part of what
the repository should store and version. A hypothetical project where the
only changes was a "touch" would generate a new version for each commit with
a different timestamp.
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:00:42 2005